Update Flask version to 2.0.*, along with associated requirements

[zenmonkeykstop]

Description

Core requirements (Flask, Werkzeug, Jinja, etc) are lagging behind their most up-to-date available versions by quite a bit. This complicates the process of upgrading other requirements with shared dependencies (e.g. the click package).

An attempt at updating these requirements to recent versions has been started in https://github.com/freedomofpress/securedrop/tree/add-https-to-dev - this has uncovered some juicy issues:

• some application requirements are duplicated in test requirements, and as test requirements are installed last in the dev Docker container, application-side updates to those requirements are not reflected in dev (current workaround in branch is to swap the order in which requirements are installed)
• Pylint now complains with an E0237: assgning-non-slot error when attributes are assigned to the flask.g object - see Assigning to attribute flask.g.[...] not defined in class slots (assigning-non-slot) pallets/flask#4020 for more. (The simplest workaround for this is to disable pylint assigning-non-slot warnings, either selectively or globally)
• There are some new mypy errors of note:
  • Adding attributes to the Flask object (to make them "global") throws an error like error: "Flask" has no attribute "instance_config" - see Mypy issue if assigning to AppContext or Flask pallets/flask#4167 for an explanation
  • stricter type checking is causing errors like this one

A more informed attempt would probably start by cleaning up the existing requirements so that the test requirements are in sync with securedrop-app-code requirements, and then address the mypy globals issue, since that is likely to have the biggest impact on application code.

Prerequisite tasks for this dependency update:

• Refactor encryption logic to fix type-checking and improve tests (CryptoUtil 3/3) #6160
• Update flask-babel: remove refs to app.babel_instance (done in add-https-to-dev branch)
• Remove app.storage attribute, refactor Storage as global #6201
• Remove app.instance_config attribute, refactor instance_config as global #6202
• Reduce or eliminate the use of flask.g thread locals #6203

[nabla-c0d3]

A few things I thought of:

Adding attributes to the Flask object (to make them "global") throws an error like error: "Flask" has no attribute "instance_config"

Dynamically adding attributes to the Flask object (or any object) is a bit of an anti-pattern as it causes various problems, one of them being that the dynamically-added attribute is not type-checked at all. Hence, in the context of type-checking, mypy is "right" to complain about it.

I described this problem in more details in #5599. I am close to being done with the CryptoUtil refactoring to specifically address that (next PR at #6087, and after that one there will probably be one more).

I think it would be valuable to remove dynamically-added attributes from the code base. After CryptoUtil, I think there will be a couple more (I remember Storage being one of them).

Pylint now complains with an E0237: assgning-non-slot error when attributes are assigned to the flask.g object.

Similarly, using flask.g is a bit of anti-pattern too as it cannot be type-checked either (the content of g is fully dynamic).
Even Flask recommends against using it in https://flask.palletsprojects.com/en/1.1.x/design/#micro-with-dependencies and I also talked a little bit about it in #5694 . I think the usage of flask.g should be reduced to the minimum.

Overall, both patterns (dynamically adding attributes and using flask.g) are "incompatible" with type-checking (and have other problems). I think there's value in moving away from them. Not really what this GItHub issue is about but I thought I'd give my opinion 😅.

[zenmonkeykstop]

Thanks @nabla-c0d3 - it may not explicitly be the topic of the issue but it does seem necessary for the version bump and is extremely useful feedback! Getting type checking working against CryptoUtil is probably the most critical part security-wise - thanks for the work you've done already. IIRC storage and instance_config are also dynamically attached, and can probably be refactored out as globals in much the same way.

I'll take a look at #6087 on Monday and maybe also see about the requirements cleanup mentioned above (which isn't related to the code refactoring, but probably still needs doing).

[zenmonkeykstop]

One gotcha here is that flask-babel's Babel object attaches itself as the babel_instance attribute to the Flask app, so for that one an approach other than the one in the CryptoUtil refactor may be required (or we could suppress that single mypy error).