Create tool to detect database changes between branches/commits

[AndrewSisley]

Needs to flag if anything changes between branches/commits - e.g. if the cid format changes between a feature branch and develop, or develop and master/main.

Could be done in a few ways, but need to make sure that it doesn't block the build and will not clutter up go test ./.... Code could live in another repo. Could be a test of go-tests dependent on an environment variable (and not run by default). Doesn't have to be written in Go, but if so check in with other team members/CTO first.

Check should do something similar to:

• git checkout and pull branch a (e.g. develop)
• create a new database
• write a whole of stuff to it
• dump database into variable/file
• repeat for comparison branch (e.g. sisley/feat/I123)
• compare outputs and notify

Would be good to hook it up to the CI system github PRs somehow in the future, but should be considered out of scope for this issue (but don't do anything too weird that might make that overly difficult).

[AndrewSisley]

Thought some more about this:

• Should not based on direct calls to the defra code base (and should use the CLI, or potentially, but hopefully not - the http api), it should be possible to use https://pkg.go.dev/plugin but if the method signatures have changed between commits then it will break this
• Should be possible to integrate it with a Breaking changes dir/list, and have the tests fail if the breaking changes are not documented there - could be a set of human-readable .md files with perhaps a hash of the original, and new print dumps. Test code could scan for files not present in the old branch/commit and compare the hashes with the print dump outputs. I don't think there is a sensible way to link these files to commits (which would be nice) due to interactive rebasing and PR squashing.
• I cant yet think of a good way of determining which branch to compare against (git log might mislead if a feat. branch is based off another feat. branch but the current will be merged into develop without the base going in first). Suggest using environment variables, with the current branch being one default and develop being the other default.

[AndrewSisley]

Had a bit of a think on this lately, and I think it should be feasible to further modify the integration tests to allow them to run across two versions, orchestrated by a controlling process (name: conductor in the text below):

1. Conductor starts running tests, triggered by the setting of an environment variable
2. Conductor checks out develop branch (configurable via env. param?) in new t.TestDir()
3. For each test:
   3.a) Conductor generates a t.TestDir()
   3.b) Conductor spins up a new process running the develop branch using badger-db in 3.a, this process runs the test up until the db.ExecQuery call - setting up the database with test data/schema
   3.c) Conductor runs the test on the current branch from the db.ExecQuery call against the now-populated badger-db in 3.a, and raises failures just like any other Go test

Would give us a high degree of coverage for minimal effort (compared to some kind of snapshotting system). It doesn't have to be done this way, but is currently my favourite method.

Would need/like to hook it up to the CI system to trigger some kind of acknowledgable warning on PR, but that could be done later if needed (running manually is better than not running). Or, on re-read of my earlier comment - integrated with a breaking-changes directory!

[AndrewSisley]

Blocked on #128 (badger-db tests) and #141 (conflicts)