Refactor Tests + Light Other Refactoring

[confused-Techie]

Requirements

• Filling out the template is required.

• All new code requires tests to ensure against regressions.

  • However, if your PR contains zero code changes, feel free to select the checkmark below to indicate so.

• [X] Have you ran tests against this code?

• [ ] This PR contains zero code changes.

Description of the Change

While I know it's worrisome to modify tests after creation, rest assured this PR changes no content of tests other than the paths within require statements.

This PR aims to reduce how messy some aspects of the codebase has become.

Namely the exists of multiple folders within ./src that were different folders for tests to reside in. As well as the existence of dev-runner folder within ./src that contained the initial-migration of database data for the test suites, as well as the built in mock GitHub ExpressJS Server.

Firstly, this PR removes ./src/git.js since it is no longer used within the codebase, it's accompanying test file and the GitHub ExpressJS Server.

Otherwise this PR moves all tests into the ./test folder, using the file names to differentiate between different test types, such as unit, integration, vcs. Although these test types matter a whole lot less with the new mock capable framework used by the VCS modules, which means things like a mock GitHub server are no longer needed once tests are fully converted.

Additionally better mocking could allow the other edges of the testing platform to be remedied such as interactions with Google Cloud.

Since otherwise by mocking web requests from VCS, the Dockerized DB (That has existed for some time) Google Cloud Storage interactions are the last sections of code that haven't been fully tested due to the fact they reach the outside world. But mocking this we could fully be able to run all tests without much issue or concern.

---

While this PR doesn't address all the goals stated above, it starts the changes needed to make it happen.

[confused-Techie]

So I did end up having to modify a few tests that had somewhat relied on the state of the database. Things like checking the order of packages returned by checking specific package names returned. Which could change if packages are deleted in another test, or receive more or less stars in other tests.

This does bring up a great point, something I'd love to see is to ditch the global state of the db during tests. Where rather we could have each test clear the whole db except tables. Then we have each test create the resources it'll be used within their test. So there is less guesswork, and makes things much more obvious