Unexpected behavior with auto_redirect

Problem/Motivation

This is a follow up to the issue https://www.drupal.org/project/autologout/issues/3101732 →
I have experienced some unexpected behavior with the fix that in short check if there is a destination to user/id path that differs from the current user id.

1. The check does not consider if this is a login request or just a call during a session that happens to have destination meet to the criteria, making requests getting dropped.
2. I have no clue why but I have seen it happens several times in prod, that the 'auto_redirect' entry in session has been reset making the check go in and drop request. This has unfortunatly been in buisness critical POST requests making the form in these case not submitted. Not sure why that should happens, either the request->session is not a reliable storage or there is some other issue with that.
3. When this is triggered we set a redirect response to the current user page. Not all sites has the user page as login destination, but that I would say is a site implementation issue to fix if so, since the default behavior in drupal is the user page as the login destination
4. When this is triggered we set a redirect response to the current user page. The request is effectivly dropped then. How ever drupal core as its redirect response subscriber (https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/lib/Drupal/...) will set the response back to the destination parameter set in the request anyway, se we effectivly wins nothing. Only losing an aborted request.

Steps to reproduce

• Create 2 user as "abc"(userid=2) and "xyz"(userid=3)
• Login as user abc and go to any page
• Go to a page (for example a form submit) that has a destination parameter ?destination=/user/3
• You are attempted to be redirected to /user/2 but is in fact redirected to to the /user/3 page anyway but request is aborted. Any potential form submit methods is never called

Proposed resolution

1. First, investigate if this is a behavior that we want. My opinion is that this is more a issue of the drupal core RedirectResponseSubscriber that is a bit to general I many occasions
2. If kept, make sure this is checked only on login where it is originally intended. Either to make use of the autologout_timeout=1 query parameter or in the user_login hook somehow.
3. If kept, make sure the respons is in fact redirected somehow. Perhaps should this be put in a response subscriber instead set to be run after core subscriber to reset the redirect response.

Remaining tasks

User interface changes

API changes

Data model changes