Bib records may not have a 901$c after upgrade

[Jeff Godin]

evergreen.maintain_901 attempts to maintain the 901$c field to contain the internal record ID.

As such, OpenILS::WWW::Exporter (and other code?) has had its 901$c mangling-at-export capabilities removed.

(see: bd55628c93f158d9318af291acbfd0cc2e30682a for removal of 901mangling from OpenILS::WWW::Exporter)

It appears that on an upgraded system, records that have not been otherwise modified will lack 901$c values -- because nothing has tripped the maintain_901 trigger. These values will not be filled in at export time, because they are expected to be maintained by the database.

Observed on an Evergreen 2.1-ish system. Almost 2/3 of examined bibs lack a 901$c -- presumably because they have not been updated since evergreen.maintain_901 came to be.

Restoring the 901$c aspects of OpenILS::WWW::Exporter would work around the immediate symptom, but perhaps an upgrade script to force the trigger -- possibly only when the existing 901$c does not match the bre.id?

Note: the lack of 901$c seems to be more of a "bug" than similar issues which affect records when adjusting the global flags cat.maintain_control_numbers and (possibly) cat.bib.use_id_for_tcn