Prevent cache backend reuse

[espadolini]

We're currently relying on opening the same sqlite databases as the backend for our caches (in data_dir/cache/componentname) because we also use the cache as some sort of persistent resource storage to be used in case auth is not available at start time; however, all non-auth services except for SSH will outright just block waiting for a connection to auth at init time, and the SSH service will get halfway through the init and then it will block waiting to see if the connection to auth is direct (meaning that the service should open a listening port) or goes through the proxy (meaning that the service should only serve connections through the reverse tunnel) - as it stands, cold starts and restarts while auth is not available are effectively only working for ssh if proxy is available and the ssh service runs in reverse tunnel mode (and even then, I'm not sure that anything would be usable while the proxy itself has no connectivity to auth).

In addition, during restarts (both in-process restarts caused primarily by CA rotations and graceful process restarts caused by HUP/USR2) we end up opening multiple instances of Cache that use the same underlying storage (unless we're using in-memory caches). There isn't (and probably can't be) a mechanism that lets two caches gracefully use the same backend storage, especially not across the process boundary (the fanout system is entirely in memory), and as it stands, the caches will fight between each other and leave the underlying storage (and thus the actual view that the cache has over the upstream) in a potentially incoherent state.

Given that the persistent cache storage is not actually used in practice (as soon as a connection to auth is established each cache will wipe itself and fill itself with fresh data) and that the particular way it's supposed to be used is actually broken in every occasion except a cold start, this PR removes the concept of cache backend reuse, by changing the default cache type to in-memory, setting up a temporary directory that's unique for each TeleportProcess instance to house the sqlite cache backends if the cache type is explicitly configured like that, and removing the (useless, at that point) cache tombstone mechanism.

Support for on-disk caches is maintained for the sake of (partial) backwards compatibility, even though memory usage for an in-memory cache for the Node component wouldn't meaningfully increase over the memory used by RBAC for one or two inbound connections anyway.

Persistent resource storage for startup while auth is not available should be handled in some other, more explicit (and perhaps opt-in?) way but is out of scope for this PR which just addresses the cache correctness problem that we currently have during restarts with on-disk caches.

Product decision:

• this PR changes the default cache type to in-memory. Should we leave it as sqlite instead? Should we get rid of sqlite caches altogether?

[espadolini]

Closed as per @zmb3 in favor of disabling on-disk caches altogether in #11386.