Option A ::

...

Clean up Int tests

How it works:
- Consolidate, de-dup and clean up unnecessary int tests
- Options:
  - Switch to new test tool like eftest that allows for parallel test runs (kaocha does not allow for parallel test runs) –
    - parallel runs do not work for int tests because tests require specific database state that is shared and reset every new test. Running in parallel will mess up the db states. BUT maybe we can use this for unit tests?
  - Parallel testcontainers? (Ask Tyler)
  - Setup each namespace to share one instance of db, elastic, etc to reduce # of times we need to reset these resources
  - Move some int tests to unit tests
  - Introducing multi-threading in applicable int tests (example: cmr.system-int-test.misc.health-test) – we may not have the computational power for this in docker
  - Should int test should be blocking step at all in merge requests??
    - Idea: Keep int tests as daily runs, and then unit tests on commit changes
  - Is there a code coverage threshold that would make us more comfortable to rely on unit tests?
    - Would we still do the int tests if we separated search and ingest into their own projects?
PROS
- No change to workflow necessary
CONS
- Will take time to go through all tests and think about consolidation efforts
- I suspect this will not give us that big of a time save

...