compatibility with Werkzeug 2.2 and Flask 2.2

[davidism]

• Revert Modify expand_login_view to allow for subdomain and host matching for login_view #462 and Only preserve subdomain or host view args in login redirect #663. Dynamic domain values should be managed with app.url_value_preprocessor and app.url_defaults, not by trying to re-parse the rule on every build.
  fixes incompatible with werkzeug 2.2.0, can't import parse_rule #686
• Store the user on g._login_user instead of _app_ctx_stack.top.user.
  fixes use g instead of _app_ctx_stack for Flask 2.2 compat #690

[coveralls]

Coverage increased (+1.1%) to 99.81% when pulling 359fb00 on pallets-compat into 62c04f4 on main.

[jwag956]

I'd like to point out that this seriously breaks anyone who has a user_loader or request_loader - which I believe are public API entry points. While Flask 2.2 is going to deprecate using _app_ctx_stack - this change immediately forces anyone to either only support this latest version or do checks to see whether _login_user attribute is set.
Possibly an alternative change would be to ADD this new g._login_user and note in release notes that the other will be going away in the future....

In any case - thanks so much for keeping this package alive and up to date.

[davidism]

You should not be checking any internal values directly. This change should be invisible to the user. If you don't believe that's the case, open a discussion about that.

[potiuk]

Actually I have a strong case supporting it, This will break openid integration for users of Airlfow using google open id integration. It's not your fault of course here @davidism - it's the client's fault, but I just wanted you to know that it does affect your users (I am openinig discussion momentarily).

[davidism]

• This change is backwards compatible with existing versions of Flask and Werkzeug. user_loader, request_loader, and login_user continue to work as they always have.
• In general, do not rely on internal implementation details, for Flask-Login or any other library. If you need functionality that is only available internally, make sure you really need that and can't rework your own code to use the library as expected, then open a feature request otherwise.
• Use minimal, reproducible examples to demonstrate issues.