Refactor TransactionManager tests

TransactionManager's tests have grown quite unwieldy through various changes. There's only one type of step which makes it also difficult to control the order of execution without ever increasing number of flags as evidenced by SkipStartManager, RestartManager and StopManager. To test some upcoming changes, we also need to be able to exercise multiple transaction running concurrently. This commit refactors the tests to address the pain points:

1. The step type is broken into multiple distinct types. This allows for better control on the order of operations. The various flags for controlling manager lifecycle are no longer needed as there are now clear steps to start and stop a manager which the test cases can use or omit as needed.
   • As the transactions now live over multiple steps, it's easier to test various situations where the manager stops for example before a Commit or before Begin and so on.
   • Testing concurrent transactions in a predictable order is also possible now, as we can run for example two Begin calls sequentially and commit them in whatever order we want.
2. Intermediate states are not asserted anymore, such as the log entries prior to their pruning. This keeps the tests leaner but also ensures we are testing behavior instead of internals. There are cases that test the manager crashing at certain points during execution, which assert the behavior that the manager can recover from crashes using the WAL entries.
   • The end state of the repository is still asserted. This ensures the repository is in a good state at the end of the test.
   • As the intermediate state is no longer asserted, there's no need for the test suite to synchronize manually between every transaction commit. This means we actually test the synchronization within the manager itself. Currently it means we don't admit another transaction before the previous one has been successfully applied to the repository. As we now rely on the synchronization in the manager itself, we can start iterating on the synchronization inside the manager and know that the tests are testing it.
3. There were multiple ways to install hooks before, both on start up and on a running manager. Installing running manager needs proper synchronization which then hampers testing the manager's synchronization. The hooks are now only installable when the manager starts.

Part of #4792 (closed)