[DEV] move test environment into Go

[rainest]

Short Description
Replace the specialized test container executed with supporting infrastructure via docker-compose via bash with tests that go test can run mostly independently.

Definition of Done
To the extent possible, go test invocations can provision the supporting environment necessary to test PCS and run tests without prior environment preparation.

External environment management should be limited to overriding test defaults: for example, if the tests allow choosing a storage environment, the Makefile/Actions can pass STORAGE=etcd or STORAGE=postgres to choose which. Go will still be responsible for creating the Postgres or etcd instance, however.

The testcontainers project provides a library of supporting infrastructure containers that can be configured and started from Go (e.g. https://golang.testcontainers.org/modules/vault/). For SMD and the like we'd need to create our own.

Additional context
The current test scaffolding doesn't allow the use of a debugger or running individual tests, which is painful for development.

Adding new tests requires knowing which of several layers (the code, the test image, the test docker-compose configuration, the script that invokes docker-compose, the Makefile, and the Actions workflow) to add new configuration to. A base layer that can operate independently with overlays over top is easier to work with: you add configuration to the base first and only elsewhere when you need to override.

[rainest]

Alongside this, we will need to account for cases like https://github.com/OpenCHAMI/power-control/blob/v2.7.0/internal/domain/transitions_test.go#L107-L111, where individual test suites are currently responsible for standing up their own data store/Vault connection/etc. rather than receiving them from a central suite.

That's probably big enough for its own issue, but effectively depends on this.

[rainest]

Attempting to convert transition behavior tests to the Golang harness and providing them a means to run against Postgres has gone less than swimmingly.

Using a separate package with integration tests across the service is the only easy way to share go test-instantiated containers for dependencies, and existing PCS packages using packages as pseudo-structs is at odds with this.

Existing tests rely on being package-internal to access private variables with unclear relationships to the tested component in non-standard ways. Here, distLockMaxTime and such are defined in power-status.go, but apparently necessary for the transition handler--that relationship is difficult to suss out because there are no struct boundaries (the package is kinda several structs glued together with illegal cable connections between one another) and because the transition processor is 800LOC.

That transition processor has not much input and zero output (or concurrency channels), so tests can't really know whether it succeeded or not, or provide data to it directly.

Tests mostly call the function the HTTP API does to retrieve the transition after, to confirm its expected state, but sometimes wait for a bit.

While TriggerTransition is essentially equivalent and exported, it calls doTransition() via goroutine, so it neither has useful returns (it echoes its input AFAICT) nor knows when doTransition() has finished.

Absent a clean rewrite of everything, we can possibly reach an ugly middle ground by providing a generic suite that instantiates separate containers for each package. We'd probably need to then duplicate that suite code for the storage package--it needs to set up storage providers, and having it in a package external to storage results in import loops if you then try to test storage with it.