mod-remote-storage fails to recover from invalid token

Overview:
If the Okapi authentication token for the system-user for mod-remote-storage is invalidated, the module does not recover and the token apparently needs to be manually updated in the system_user_parameters table. This is obviously extremely brittle, as the authentication token is not guaranteed to remain valid indefinitely (and indeed it would be a security risk if it was never invalidated).

Steps to Reproduce:
On a running system with mod-remote-storage, restart mod-authtoken with a new signing key to force invalidation of all tokens.

Expected Results:
Changing the location of an item to a remote storage location should add the item to the accession queue.

Actual Results:
The item is not added to the accession queue, and the following error appears in the log:

19:54:27 [] [] [] [] INFO  ccessionQueueService isEffectiveLocationChanged: true
19:54:27 [] [] [] [] ERROR KafkaConfiguration   Error in process with Exception org.springframework.kafka.listener.ListenerExecutionFailedException: Listener method 'public void org.folio.rs.integration.KafkaMessageListener.handleEvents(java.util.List<org.folio.rs.domain.dto.DomainEvent>)' threw exception; nested exception is feign.FeignException$Unauthorized: status 401 reading InventoryClient#getInstancesByQuery(String); nested exception is feign.FeignException$Unauthorized: status 401 reading InventoryClient#getInstancesByQuery(String) and the record is org.apache.kafka.clients.consumer.ConsumerRecords@677547a9

Additional Information:
Restarting mod-remote-storage does not allow it to recover, nor does it help to set the okapi_token column in system_user_parameters to NULL. The only workaround I found was to log in to the FOLIO environment as the system-user and manually update the entry in system_user_parameters with the new token.

Interested parties:
dbottorff arnt@uchicago.edu