PHO-95: holdings with nil enum match any htitems

[aelkiss]

Background

A partner reported that an OCLC number they hold did not appear to match any items in HathiTrust in their "ETAS overlap report".

• A HathiTrust item is considered to be a multipart monograph (MPM) if it does NOT have format SE (serial) and ANY item on the same catalog record has an enum:
  https://github.com/hathitrust/holdings-backend/blob/main/lib/calculate_format.rb#L17
  https://github.com/hathitrust/holdings-backend/blob/main/lib/calculate_format.rb#L43-L47

Whether a holding matches a cluster (i.e. one or more catalog records sharing a set of equivalent OCNs) or a HathiTrust item is dependent on context.

• Cost report: For MPMs, If a member reports holding an OCN but none of their reported enums match any of the enums on a HathiTrust item, they are still considered to hold it for the purposes of whether they pay a share of the cost for that item: https://github.com/hathitrust/holdings-backend/blob/main/lib/overlap/ht_item_overlap.rb#L27
• Production holdings table (used for ETAS access): As with the cost report, we check organizations_with_holdings_but_no_matches.include?(@org) for copy_count: https://github.com/hathitrust/holdings-backend/blob/main/lib/overlap/multi_part_overlap.rb#L10-L14 in the production holdings table
• ETAS overlap report: This uses only matching_holdings, which does NOT account for the case when no member-reported enum matches any enum for items in HathiTrust: https://github.com/hathitrust/holdings-backend/blob/main/lib/overlap/multi_part_overlap.rb#L36-L40 ; https://github.com/hathitrust/holdings-backend/blob/main/lib/reports/etas_organization_overlap_report.rb#L82. The intended semantics appear to be that a holding matches an item either if their n_enum matches, or if the holding has no reported n_enum.

This behavior is complex and confusing because it was replicated from the old holdings system without a comprehensive review of the requirements (that is, the requirements were taken to be the observed behavior of the old system.)

https://hathitrust.atlassian.net/browse/HT-2726
https://hathitrust.atlassian.net/browse/HT-2727

Changing the behavior overall is out of scope here (either changing the behavior for the ETAS overlap report so that it includes cases where no enum matches, or my preferred option of doing away with enum-based matching entirely as we do with serials)

See also the investigation and notes on https://hathitrust.atlassian.net/jira/core/projects/TTO/board?groupBy=status&selectedIssue=TTO-168

This change

This change allows holdings with nil normalized enumeration (n_enum) to match HathiTrust items. This appears to be an unanticipated case with the data, but does not change the underlying semantics of matching. Such holdings/items will match and appear in the ETAS overlap report.

Separately, we should determine whether the data loading process is unexpectedly loading nil values for n_enum, or if this is a byproduct of data from the old system.

Because the cost report and production overlap table already consider such cases to match via organizations_with_holdings_but_no_matches, this should only affect the ETAS overlap report -- that is, the items/holdings already match for the cost report and production holdings table.

[coveralls]

coverage: 95.034% (+0.02%) from 95.012%
when pulling 815b05b on PHO-95-match-nil-enum
into 8398573 on main.

[aelkiss]

This is the new test; the other changes here are just trying to make it a bit more clear what's going on.

[moseshll]

Ran fine, no red flags once I got my head wrapped around the fact that blank? was legitimately being provided by ActiveSupport.