We need to be sure some of the guarantees that EtcdConfig promises hold true, specifically:
- In case the remote server is unresponsive (see T156924#3269464 for more details)
- the call to etcd will timeout and what is in cache will be used.
- At most one concurrent call to etcd will be made, and all other requests will use the cache
- No etcd connections are leaked
- In case the remote server sends an empty response the data in cache will be used
- In case the remote server is down at the startup of the application server, our monitoring requests will fail, depooling the server
- If more than one server is listed, either via dns discovery or via a list of servers, and one is unresponsive, the next one will be called
- The server sends a response that takes longer than our timeouts to be received, the cache will be used
A good chunk of these tests can be easily run in deployment-prep.