* Log failed connection attempts in monitorProxies
* Update coordinator list from the cluster file after failing to connect to all coordinators
* Wiggle and upgrade test with legacy version monitoring; updating tests to use 7.1.9
* Update coordinator list from the cluster file: addressing review comments
* Update coordinator list from the cluster file: addressing review comments
* Wait on future for all setAndPersistConnectionString calls
* Defer recoveredDiskFiles wait if Encryption data at-rest is enabled
Description
In the current code ClusterController startup wait for 'recoveredDiskFiles'
future to complete before triggered 'clusterControllerCore' actor, which
inturn starts 'EncryptKeyProxy' (EKP) actor resposible to fetch/refresh
encryption keys needed for ClusterRecovery as well interactions with
KMS.
Patch addresses a circular dependency where StorageServer initialization
depends on EKP, but, CC doesn't recruit EKP till 'recoveredDiskFiles' completes
which includes SS initialization. Given 'recoveredDiskFiles' is an optimization,
the patch proposes deferring the 'recoveredDiskFiles' future completion until
new Master recruitment is done as part of ClusterRecovery (unblock EKP singleton)
Testing
Ran 500K correctness runs: 20220618-055310-ahusain-foundationdb-61c431d467557551
Recorded failures doesn't seems to be related to the change.
* Add an DD tenant-cache-assembly actor
* Add basic tenant list monitoring for tenant cache.
* Update DD tenant cache refresh to be more efficient and unit-testable
* Remove the DD prefix in the tenant cache class name (and associated impl and UT class names); there is nothing specific to DD in it; DD uses it; other modules may use it in the future
* Disable DD tenant awareness by default
* fix a fault injection bug in txn store recovery
* Update LogSystemDiskQueueAdapter.actor.cpp
typo
* recoverLoc can be overwritten, so on reset use the stored range start
Currently, a std::string is copied unnecessarily for every key and value
in a trace event.
This actually showed up in a jemalloc heap profile while I was
investigating something unrelated. I was surprised to see it since these
allocations should have a very short lifetime.
