Add a session backend to store session data in the database

[blag]

This PR re-implements modified portions of Flask-Session to store session data in the database.

Things to note:

• This is my first major PR
• I'm not sure the added test file is in the right place
• Please double check my migration documentation is acceptable and complete

TODO:

• Tests

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[jedcunningham]

We need to add it to NOTICE as well.

[jedcunningham]

This will need to be moved into the right spot for 2.2.4 (e.g. a different "revises id"), but I'm most likely going to pull another revision back to 2.2.4 tomorrow so hold off for now. At least this comment will remind us we need to do it.

[blag]

@jedcunningham Some of the code your wanted changes to is the vendored in code. I intentionally made as minimal modifications to that code as I needed, with the intent to possibly make a PR to upstream Flask-Session, get that merged, and migrate to using that (and removing our vendored code). The more and more in-depth modifications we make to the vendored code, the more difficult it will be to switch in the future.

I'm happy to make the changes you noted if you'd still like me to (please let me know), I just wanted to bring that to your attention first.

[dstandish]

@jedcunningham Some of the code your wanted changes to is the vendored in code. I intentionally made as minimal modifications to that code as I needed, with the intent to possibly make a PR to upstream Flask-Session, get that merged, and migrate to using that (and removing our vendored code). The more and more in-depth modifications we make to the vendored code, the more difficult it will be to switch in the future.
I'm happy to make the changes you noted if you'd still like me to (please let me know), I just wanted to bring that to your attention first.

On this topic, thinking out loud...

If we're trying to be able to easily understand what changes we've made to the vendored code, should we merge it in first with no changes? then make PRs on top of that which modify its behavior?
Then we'd be able to tell exactly what we did to it (instead of vendoring and changing in one commit / pr).
And it would make the PRs easier to review too.

Alternatively I don't think we do submodules 'round here but is this a valid case for it?

[ashb]

If we're trying to be able to easily understand what changes we've made to the vendored code, should we merge it in first with no changes? then make PRs on top of that which modify its behavior?

In a case or two previous to this we have merged the PR without squashing (manually on the command line).

Outdated

[blag]

@dstandish That's a good call, but it's looking less and less likely that our changes are going to be palatable to the maintainer of Flask-Session. If the changes we need won't ever be merged into Flask-Session, then our modified vendored code just becomes...our code, with an additional copyright line/header.

A "middle path" of this would be to start maintaining our own fork of Flask-Session, merge in the changes that we need, maybe merge in a few more unmerged PRs from Flask-Session, and have our fork become the friendlier (than Flask-Session) session package for Flask. But I don't want to sign the company up for that responsibility without some consensus and blessing, and I don't really want to maintain my own personal fork of Flask-Session specifically for Airflow.

I'm happy to do whatever it takes to get this merged, but I will need some guidance on how to get there.

[jedcunningham]

Superseded by #21478.