Use Case

As a... driver developer
I want... to have specifications repo (https://github.com/mongodb/specifications) defined as submodule
So that... I can sync changes using git utility

User Experience

• Instead of copying test files manually during spec sync use git submodule status|update|etc.
• Less error-prone, easier to review changes

Dependencies

• N/A

Risks/Unknowns

• None, we already use unified test runner and everything works as it should. The only complication might be with path inconsistency (our internal folder/file structure is not 1-1 to spec repo), so changes in files that import/run tests would be needed.

Acceptance Criteria

Implementation Requirements

• All spec tests are in the same state as before (either passing or skipped)
• Actual changes (spec test files) that have been changed (different from our repo state) need to be examined (is it outdated test that we keep, or something else). We need to make sure that only the mechanism of importing tests changed, not the content.
• If necessary, we should create our own copies of tests that would need to be skipped or that are removed post-sync if we’re using older versions of those tests for our own coverage (use our `TestBuilder` and `UnifiedTestSuiteBuilder` for this)

Testing Requirements

• N/A

Documentation Requirements

• Find&Replace all places where spec tests are mentioned in docs (readme.md and test/readme.md)
• Team practicies/First responder guide should also be updated if they have manual process described

Follow Up Requirements

• N/A