[BB2-2336] Upgrade Python from 3.7 to 3.8 (LTS) for BB2 web server

[JFU-GIT]

JIRA Ticket:
BB2-2336

User Story or Bug Summary:

Context:

AMI Python 3.7 LTS is Jun 2023, so need to schedule that task in next 12 month. Need to do some research into what version to upgrade to 3.8

AC:

The BB2 AMI updated with python 3.8, and BB2 server works as expected:

1. Passing all the unit tests
2. Passing all the integration tests, and selenium tests
3. Deploy to LLE for more testing
4. Deploy to SBX and monitoring for any issues for 1 week: NR, Splunk
5. Deploy to PROD and continue to watch for issues

What Does This PR Do?

This PR is for the BB2 server code base changes due to python upgrade from 3.7 to 3.8 LTS:

1. Changes made to BB2 requirements - bump python to 3.8 LTS will trigger version upgrades for various dependencies
2. Based on the locked dependencies, provisioned the binaries under vendor folder
3. Changes made to Dockerfile, Dockerfile.selenium, Jenkins pipeline files for CI checking to use Docker containers under python 3.8
4. Provisioned a python 3.8 Docker image on BB2 ECR (this is in a PR on bluebutton-web-deployment repo)
5. Migration files generated with some customization on Application model - client_secret handling

What Should Reviewers Watch For?

1. Perform the checking and testing as required by AC
2. Perform a migration on local BB2 - detailed steps see comments in ticket BB2-2336
3. Perform the deploy and migration on TEST (this is performed when everything checked on local ENV), because the migration and code deploy theoretically will cause the Application model in a in-consistent state during the small time windows, very small window - but need to discuss if we need to declare a down time

If you're reviewing this PR, please check these things, in particular:

• TODO

What Security Implications Does This PR Have?

Submitters should complete the following questionnaire:

• If the answer to any of the questions below is Yes, then here's a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence: N/A.
  • Does this PR add any new software dependencies? No.
  • Does this PR modify or invalidate any of our security controls? No.
  • Does this PR store or transmit data that was not stored or transmitted before? No.
• If the answer to any of the questions below is Yes, then please add StewGoin as a reviewer, and note that this PR should not be merged unless/until he also approves it.
  • Do you think this PR requires additional review of its security implications for other reasons? No.

What Needs to Be Merged and Deployed Before this PR?

This PR cannot be either merged or deployed until the following pre-requisite changes have been fully deployed:

• CMSgov/some_repo#42

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime, etc)
• No migrations

Submitter Checklist

I have gone through and verified that...:

• This PR is reasonably limited in scope, to help ensure that:
  1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
  2. There isn't too much of a burden on reviewers.
  3. Any problems it causes have a small "blast radius".
  4. It'll be easier to rollback if that becomes necessary.
• I have named this PR and its branch such that they'll be automatically be linked to the (most) relevant Jira issue, per: https://confluence.atlassian.com/adminjiracloud/integrating-with-development-tools-776636216.html.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
• All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
• Reviews are requested from both:
  • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
  • Any relevant engineers on other projects (e.g. BFD, SLS, etc.).
• Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
  • Please review the standards every few months to ensure you're familiar with them.

[ajshred]

Great work James! Thanks for the walkthrough!

[dtisza1]

This looks good to me!

• Performed local testing w/ migrations from r105 to PR branch.
• Code changes look good after several passes thru.
• Our testing via a TEST canary is going well.

Great work on this!!!