Spike: Determine and implement strategy for handling X-Okapi-Token expiration/invalidation

If the X-Okapi-Token expires or becomes invalid, FOLIO will respond with unauthorized errors. When this happens we could do a couple things:

1. Ignore it and just fail every command (our current strategy - not ideal).
   • This would likely (should confirm) issue screen viewable errors to the SC and would require staff intervention to reconnect.
   • Need to ensure every command can return some sort of reasonable SIP2 response when this type of failure occurs.
2. Send an ACS status message indicating the ACS is offline as a response to all messages.
   • It is unclear what would happen next here. Ideally, the SC would start sending login messages. It may send SC status messages instead. We'd need to experiment with/solicit information from various SCs/SC vendors to determine the behavior.
3. When a FOLIO command fails with unauthorized, we could attempt to login and, if successful, re-issue the failed command.
   • This requires edge-sip2 to hold on to the SCs credentials from the original login command. This may be viewed as a security issue.
4. Kill the connection and hope the SC will reconnect with the login command.
5. Something else? Maybe existing SC vendors can suggest how to handle this.

As far as these approaches go, number 2 seems like it would be the most in-line with the intent of the SIP2 protocol. Number 3 is probably the simplest to support, but with risk. Number 1 should be abandoned, since it likely requires staff intervention... perhaps the SC will send a login if X commands fail in a row? More likely, it will take itself offline.