Change SW Aeon request submit and evaluate feasibility of merging Aeon request approaches

[taylor-steve]

SearchWorks Aeon requests are currently getting submitted here, which was temporary, to get us going:

sul-requests/app/controllers/patron_requests_controller.rb

Line 38 in ec3421c

@patron_request.submit_aeon_request(username: current_user.aeon.username)

Should this change?

#2965 added SubmitAeonPatronRequestJob, which is a different mechanism than the finding aid/EAD submission process. Is there commonality here or do they need to remain distinct?

[cbeer]

I think pushing all our requests through the PatronRequest model is a good approach. If nothing else, we'll have a place to do request/response logging, and be able to resubmit bad requests if we break something (thinking e.g. Aeon character limits).

I think there's some work to refactor PatronRequest a little before attempting to add more behavior there, including:

• extracting a generic stored API request/response model (for FOLIO, Illiad, and now Aeon)
• push the additional item information for scans (+ aeon stuff) to be a little more generic / not duplicated
• convert stored item barcodes to operate on FOLIO ids / EAD ids
• add support for extracting the necessary bib data from an EAD