Discovered in #58862: the logging system currently maintains global state in logging that is shared by all in-memory components.

However we would like certain logging properties to differ per server, for example the cluster and node ID to be reported on every log entry. Today these are stored in a global singleton, and there are conflict when we want to run multiple servers side-by-side in the same process, for example in tests.

So we'd like to have per-server logging state instead.

This is currently hard to achieve, because servers currently start async goroutines without tracking their ancestry. The logging system is often exposed to a context.Context which does not link to the current server. Also when there is a panic, there is no context.Context to work with.

One way to achieve this would be to leverage the stopper as follows:

• make the stopper register the goroutine ID as "belonging to a server"
• make the logger ask the stopper package to look up which server the current goroutine ID belongs to

We could also have the stopper map goroutine IDs to context.Context instances, which in turn carry information about which logger to use.

Alternatively, we could hack into the go runtime and add an inheritable field to every goroutine struct, which we could associate with the server's identity. (This kind of extension to the go runtime system would be useful for other areas of cockroachdb)

Epic: CRDB-6665