[BLOCKED by #1986] figure out how to re-enable zip part audit codes in AuditResults::WORKFLOW_REPORT_CODES

[jmartin-sul]

see

preservation_catalog/app/services/reporters/audit_workflow_reporter.rb

Lines 30 to 36 in 9c4eb15

	# Temporary fix for workflow-service throwing exceptions
	# because some error reports from MoabReplicationAudit are too long
	# ZIP_PART_CHECKSUM_MISMATCH,
	# ZIP_PART_NOT_FOUND,
	# ZIP_PARTS_COUNT_DIFFERS_FROM_ACTUAL,
	# ZIP_PARTS_COUNT_INCONSISTENCY,
	# ZIP_PARTS_NOT_ALL_REPLICATED

this way, replication errors are surfaced in argo the same way as other errors are, and block further versioning of problematic druids.

i wasn't sure whether to count this as a bug, or tech debt, so i counted it as both 😆

[jmartin-sul]

#1249 might obviate the need for this. or not, if we want want replication errors to halt further versioning for a druid.

[jmartin-sul]

i think we still want this, and iirc, the reason we disabled the codes was because the error messages would exceed some field length or other when workflow service's database was still in oracle (it was later migrated to postgres).

removing [HOLD]

[jmartin-sul]

The easiest way to test this is probably to just deploy the potential fix to QA or stage, and in rails console there, run: PreservedObject.find_each(&:audit_moab_version_replication!).

that'll kick off replication for all objects. you may want to double-check, but as of a few days ago, each had about 39k druids, which is not a terribly huge amount of objects on which to run replication audit. those environments are a bit of a mess, so the only downside is that those envs are a mess, so a lot of errors will probably be reported.

actually, now that i think about it, we might want to wait for #1986 to be finished before doing this.

ok, marking blocked.