Refactor circulation exceptions (PP-991)

[jonathangreen]

Description

This refactors how we are handling CirculationExceptions, so they all inherit from BaseProblemDetailException and are able to be turned into a ProblemDetail. This lets us simplify the exception handlers in the Loans controller to catch any CirculationException that the Circulation APIs might throw, and return the appropriate ProblemDetail, instead of continuing to grow the huge list of different Exceptions and actions we were handling.

Motivation and Context

Reviewing the list of unhandled exceptions we are seeing in production, multiple in the top 10 were CirculationExceptions that were not in the Except block, or were handled for some actions like borrow but not others like hold. This PR makes the handling we have here more consistent.

Having a base class BaseProblemDetailException also makes it easier to know if we are able to turn an exception into a ProblemDetail or not.

How Has This Been Tested?

• Running tests

Checklist

• I have updated the documentation accordingly.
• All new and existing tests passed.

[codecov]

Codecov Report

Attention: Patch coverage is 94.94949% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 90.21%. Comparing base (20d6e55) to head (0da3ac8).
Report is 2 commits behind head on main.

Files	Patch %	Lines
core/user_profile.py	42.85%	2 Missing and 2 partials ⚠️
core/util/http.py	88.88%	2 Missing and 1 partial ⚠️
core/util/problem_detail.py	80.00%	1 Missing and 1 partial ⚠️
core/opds2_import.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1694      +/-   ##
==========================================
+ Coverage   90.08%   90.21%   +0.12%     
==========================================
  Files         245      245              
  Lines       28170    28182      +12     
  Branches     6422     6446      +24     
==========================================
+ Hits        25377    25424      +47     
+ Misses       1848     1822      -26     
+ Partials      945      936       -9     

Flag	Coverage Δ
Api	75.99% <90.90%> (+0.19%)	⬆️
Core	59.81% <61.11%> (+0.01%)	⬆️
migration	26.95% <54.49%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jonathangreen]

This wasn't being used anywhere.

[jonathangreen]

Replaced this exception with RemoteInitiatedServerError, so that we get problem details from all the exceptions thrown by the Bibliotecha API.

[jonathangreen]

This was the only place that we used AuthorizationFailedException, everywhere else used PatronAuthorizationFailedException and it had the same problem detail, so I removed AuthorizationFailedException.

[jonathangreen]

The status codes here were changed because the only place that used these ProblemDetails was the loans controller exception handler, where they were called like this:

CANNOT_FULFILL.with_debug(str(e), status_code=e.status_code)

So they always had the status code of the exception, rather then the status code associated with the ProblemDetail. This let me drop the status code on the exceptions and just use the one on the ProblemDetail.

[dbernstein]

Looks good.