When a request fails, the server may send back a Problem Document to describe what error happened in a structured way, per https://tools.ietf.org/html/rfc7807. We should centralize its handling in our network layer (NYPLNetworkExecutor and NYPLNetworkResponder) instead of having it scattered around the app. For example, currently this is done in the Sign In VCs, MyBooksDownloadCenter, Catalog VC, OPDSFeed model and a few other places.

Things to consider:

• For SimplyE, problem documents are ONLY returned when the status code is < 200 or > 299.
• Problem documents MAY be returned in case of error, but may not. E.g., the Circulation Manager will always return a problem document for failures, but there are other pieces of software, such as load balancers, that will not.
• To understand whether a response body contains a problem document, we need to verify that (1) the HTTP status code is < 200 or > 299, AND (2) the Content-Type is `application/problem+json` or `application/api-problem+json`. (We do not use `application/problem+xml` in our software.)
• If a request fails (i.e. not a 2xx status code) AND the Content-Type does NOT indicate a Problem Document, the network layer can safely ignore the response body, and just return an error up.
• If we successfully parse a Problem Document, the NYPLNetwork* classes should pass it upstream to application level classes such as VCs, business logic, etc instead of letting them do the parsing. Some refactor will be needed in those classes.
• The message contained in the Problem Document can be displayed to the end-user, although it is not localized.