[BB2-2263] local dev docker cleanup and improve

[JFU-GIT]

JIRA Ticket:
BB2-2263

User Story or Bug Summary:

Context:

Dev Local Docker files have been one of the frequently used dev tools since its introduction, however there are rough edges there and it's nice to get them polished, it is about following best practice and also help improving the user experience.

The followings are the things to be address in this ticket:

1. root user as the current user for installing packages, this potentially can cause issue as indicated by the WARNING:
   WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behavior with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
2. Use python virtual environment as python runtime best practice (even though python virtual environment is not absolutely needed in a docker), and just be as similar to the setup on deployment target
3. Quiet excessive WARNINGS about DJANGO_SECRET_KEY by providing a place holder key

AC:

1. Non root user (e.g. 'DEV') created and python runtime installation are performed under this user
2. python virtual environment created and used as the installation and runtime context
3. the WARNINGS are reduced to minimum
4. No newly introduced warnings
5. the re-factored docker when used to start a local BB2 instance, it can be remotely attached by any popular IDE - e.g. vscode, and step into BB2 code and also dependent packages code as currently setup

What Does This PR Do?

1. Refactor the Dockerfile so that the bb2 server is setup under a non root user ('DEV')
   and the warnings are removed, do similar thing to Dockerfile.selenium
2. Give a place holder value for DJANGO_SECRET_KEY env var in (.env.sample) so that when starting local bb2 there is a place holder value for the DJANGO_SECRET_KEY, and that will suppress the warnings
3. Bonus changes: Optimized the Dockerfile.selenium by removing pip installation of BB2 server dependencies (Django etc.) which is not necessarily needed by selenium tests (now only pip install selenium, pytest, jsonschema) much smaller foot print, due to this, also need to refactor selenium test cases - no longer use Django.test TestCase class
4. Docker compose health checks added for bb2 server in selenium docker compose descriptor to prevent racing condition and improve the robustness of the services startup

What Should Reviewers Watch For?

1. Verify that the WARNINGs as specified in AC are no longer showing up during local bb2 server docker start up
2. Verify that the WARNINGs as specified in AC are no longer showing up during selenium tests run

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]

James,

Could you please put the make call back instead of duplicating that call here? It made me go look and the makefile to see what changed and it appears that nothing changed.

[JFU-GIT]

sure, here the pip show is for trouble shooting - will remove it
and original intention is getting rid of make by pull out the make target and pip install directly...

but I can put the make call back.

[ajshred]

Looks good James! Thanks!!!

[oragame]

Sorry I wasn't able to review before sprint close, this looks good James. Nice work! 👍