Add resulting bulk_merge_id of merge to Librarian Merge Queue table @mheiman

[mekarpeles]

Describe the problem that you'd like solved

Our librarian merge queue makes it rather easy to review merge requests (MRs), with a single click opening a populated merge UI in a new tab. Finding the details about a completed MR is much more difficult, and requires manually constructing a URL for the parent record, navigating to the page, and searching through the record's history for clues. It would be nice if we could click a link in the merge request table and see the results of a completed MR.

Proposal & Constraints

Whenever a merge occurs, there should be some unique bulk edit identifier. In the case of author merges, this identifier can be used to view all of the records that were merged (here is an example: https://openlibrary.org/recentchanges/2022/08/17/merge-authors/95910760). I suspect that our work merges can be displayed in a similar fashion without much effort. We can then simply replace the merge UI URL of "Merged" MRs with the URL for the merge details page, and display this link in the "Completed" merge request table.

If setting up a /recentchanges view for works proves to be too difficult, we could, at the very least, persist the bulk edit identifier in the community_edits_queue table.

Additional context

Stakeholders

[mheiman]

I've dug deep into the code, but Infogami doesn't return this identifier at the time a bulk edit occurs — it only returns the set of changed records. It might be possible to surface it with some very deep Infogami changes, but that would require also modifying all the code that relies on the current return value, and that would be a very significant change.

I have already implemented the /recentchanges interface for works (PR 6948), so this issue isn't blocking that.

We're also inserting the merge queue ID into the Infogami bulk edit data store for merges coming from the merge queue, so that should allow completing the circle between merges, the merge queue, and the undo interface. We may have a gap here for merges initiated and completed by super librarians, but that would be a separate issue.

I recommend closing this issue.

[mekarpeles]

Closing per @mheiman's research + informed suggestion. Thank you kindly for investigating!