[BB2-1982] CI Check Add user apps mgmt selenium tests

[JFU-GIT]

JIRA Ticket:
BB2-1982
BB2-2359

User Story or Bug Summary:
Context:

Currently BB2 server repo CI checking has the followings:

1. unit tests
2. flake8 Python linting
3. BB2 Integration tests
4. BB2 Selenium tests (will run optionally controlled by jenkins job flag)
   4.1 Selenium tests covering authorization flow (going through BB2 auth end points v1/v2 and with/without PKCE) and data flow after access token obtained from the auth flow, the app used is the built-in testclient

Now we have selenium tests that cover BB2 User & Apps management: e.g. create user, add app to the user account, update the app, delete the app etc.

It is desirable to add the user & apps management to the CI check selenium tests so that user account and apps management functionalities are covered, this will strengthen our position by capturing any regression in the user & apps management area.

AC:

The jenkins pipeline changed to include User & Apps management selenium tests.

SUB TASK:

https://jira.cms.gov/browse/BB2-2359

What Does This PR Do?

1. Added BB2 User and App management selenium tests to CI Check (Jenkins job pipeline)
2. Fixed the MSLS service - by re-implement the Django based app (heavier) as Flask based (lighter)
3. Refactored the logging tests and user & app mgmt selenium tests so that they are passing again

What Should Reviewers Watch For?

Make sure All BB2 tests still passing locally, and CI check with selenium tests passing including User and Apps management tests (selenium)

Check new MSLS service has less resources foot print (e.g. smaller container size)

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.

[dtisza1]

@JFU-GIT This looks good to me!

I was able to test this running locally also.

Good work on this!

[ajshred]

great work James! I approve of this PR!