The PR is updating storage server and Redwood to enable encryption based on the encryption mode in DB config, which was previously controlled by a knob. High level changes are
1. Passing encryption mode in DB config to storage server
1.1 If it is a new storage server, pass the encryption mode through `InitializeStorageRequest`. the encryption mode is pass to Redwood for initialization
1.2 If it is an existing storage server, on restart the storage server will send `GetStorageServerRejoinInfoRequest` to commit proxy, and commit proxy will return the current encryption mode, which it get from DB config on its own initialization. Storage server will compare the DB config encryption mode to the local storage encryption mode, and fail if they don't match
2. Adding a new `encryptionMode()` method to `IKeyValueStore`, which return a future of local encryption mode of the KV store instance. A KV store supporting encryption would need to persist its own encryption mode, and return the mode via the API.
3. Redwood accepts encryption mode from its constructor. For a new Redwood instance, caller has to specific the encryption mode, which will be stored in Redwood per-instance file header. For existing instance, caller is supposed to not passing the encryption mode, and let Redwood find it out from its own header.
4. Refactoring in Redwood to accommodate the above changes.
Changes:
1. Update `ConfigureDatabase` workload to test with Redwood, while previously it does not. Also when encryption is enabled, only test with Redwood and not test the migration to other storage engine types, as currently only Redwood supports encryption.
2. Update multiple restart tests so that when testing upgrade from/downgrade to 7.2, disable encryption. This is due to recent change to make encryption controlled by DB config instead of a knob make 7.3 encryption incompatible with 7.2 encryption, and 7.2 encryption is considered an incomplete feature. This is done by splitting `from_7.1.0` test directory into `from_7.1.0_until_7.2.0`/`from_7.2.0_until_7.3.0`/`from_7.3.0`, duplicating every test to these directories and add `disableEncryption=true` when needed. Except...
3. For tests that run `SnapTest`, keep them in `from_7.1.0_until_7.2.0` directory. These tests could fail with 7.2/7.3 restart test, and due to separate Joshua issue, these failures are not exposed when they stay in `from_7.1.0` directory. The plan is to only keep these snapshot tests in `from_7.3.0` (or the directory for restart from the latest version) once issues are fixed.
* proof of concept
* use code-probe instead of test
* code probe working on gcc
* code probe implemented
* renamed TestProbe to CodeProbe
* fixed refactoring typo
* support filtered output
* print probes at end of simulation
* fix missed probes print
* fix deduplication
* Fix refactoring issues
* revert bad refactor
* make sure file paths are relative
* fix more wrong refactor changes
It turns out that in rare situations, simulation can run into a case
where recovering to the point that tlog generations can be dropped takes
longer than 3s, and thus tests fail with an OOM as an ever increasing
number of tlogs are recruited and never removed.
It turns out that in rare situations, simulation can run into a case
where recovering to the point that tlog generations can be dropped takes
longer than 3s, and thus tests fail with an OOM as an ever increasing
number of tlogs are recruited and never removed.
Steve Atherton