Refactors transaction step for saving admin data

[afred]

By default, multi-valued input fields display an additional set of input fields that are blank. These get submitted by the form and are usually discarded, but because we are treating Sony Ci ID field special, it was erroneously saving additional blank values for Sony Ci ID, which was resulting in multiple players of the same media dislaying on AAPB when the record was published.

Multiple Sony Ci IDs are allowed in cases of mult-part Assets. They are stored as a serialized JSON array in the AdminData.sonyci_id field, which is related to Asset reords via a global ID field on AdminData.gid. And the global ID fields was used instead of a normal foreign key because the AssetResource used to be just Asset, and stored in Fedora, not the database, and a global ID was the closest thing to a foreign key across 2 persistence layers that we could think of :)

Fixes #882.

[afred]

@bkiahstroud and/or @orangewolf could I get an extra set of 👁️ on the logic here? This is some consequential code as it handles not only our Asset relations to Sony Ci media, but the Asset relation to the Bulkrax Importers and Batch Ingest Batches as well.

I think i tested all possibilities of adding/removing Sony Ci IDs, but did not do any kind of regression testing on persistence of bulkrax identifier or other admin data fields.

[afred]

@bkiahstroud even more of a simplification...

• Explicitly checks for sonyci_id field rather than using AdminData::SERIALIZED_FIELDS. This is an unnecessary abstraction that was put in place with the anticipation that we'd end up having more than one serialized field. It's been many years, and we have not, so I don't mind getting rid of that little bit of abstraction since that's the only place it's used. Furthermore, I think we'd be inclined to use regular JSON fields rather than serialized fields should an additional need arise.
• Moves the logic for "you cannot delete values for some fields after they've been set" into validation method AdminData#validate_undeletable_fields, which is a more appropriate location since the logic should apply no matter where the model is being used for persistence. This eliminates the need for the should_empty_admin_data_value method and reduces logic complexity in set_admin_data_attributes
• Removes unnecessary conversion of AdminData#attributes_for_update values from string, to symbol, back to string -- just keep them as strings, and we should be good.
• Uses AdminData#attributes_for_update to slice out AdminData params from the AssetResourceForm rather than looping over it, allowing us to update the

[afred]

Specs are passing for me locally, so idk what's up with the failures here. Can you replicate the failures locally?

[bkiahstroud]

Specs are passing for me locally, so idk what's up with the failures here. Can you replicate the failures locally?

I can, I get the same failures locally

[bkiahstroud]

@afred do you have changes locally that haven't been pushed up to this PR yet? For example, I don't see a new method named AdminData#validate_undeletable_fields that you referenced in this comment