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`.