POST /inventory-hierarchy/items-and-holdings Not Handling Errors Gracefully

Overview:

When there is a data issue that causes the database layer (in this case the view get_items_and_holdings_view) to return an error, it seems like the API /inventory-hierarchy/items-and-holdings does not handle the error gracefully. It returns a HTTP 500 error but at the same time the database connection gets forcefully aborted. (The DB's connection state turned into "idle in transaction (aborted)".)  Consequently, if more of these errors happened, more DB connections would get killed until there are no more DB connections left in the connection pool. mod-inventory-storage does not know that it has run out of DB connections and it does not replace the DB connections when they are being aborted. 

Steps to Reproduce:

1. Set up the database to have an instance which has an associated item that has a non-UUID statisticalCodeId, in the field item.statisticalCodeIds
2. Make this API call https://<okapi-url>/inventory-hierarchy/items-and-holdings with the instance ID in step 1, such as:  {"instanceIds":["07e95d3d-7c42-4993-9dc9-db1aed308d3e"],"skipSuppressedFromDiscoveryRecords":true}
3. a HTTP 500 code will return.  Notice in pgAdmin's dashboard there is a connection showing "idle in transaction (aborted)".
4. Repeat steps 1-3 for the DB_MAXPOOLSIZE times and FOLIO will be unusable. 

Expected Results:

• The code handles the error more gracefully so that DB connections don't get aborted
• DB connections don't get aborted.
• If connections are aborted, they should be replaced with new ones automatically

Actual Results:

• DB connections get aborted
• FOLIO applications that call inventory APIs hang and errored out, can't access the database.

Additional Information:
Some thoughts: Perhaps view need to handle the error more gracefully to relay to the caller that there is an error so that the caller could handle the error more gracefully as well. 

Interested parties: