Client trace logs should include Cluster as key where appropriate

[alecgrieser]

There are a few client trace logs that currently do not have the Cluster as an XML/log key indicating what cluster they are talking to, and I think that it would be useful to have that information to support applications where one client connects to multiple clusters. Some examples are:

1. LargeTransaction
2. LargePacket (which does contain peer information, but having the cluster as well can help aggregate requests)
3. ConnectionRejected (similar to LargePacket)

There are probably others, but the basic idea is that anything that is talking to a specific cluster or a specific FDB server on a specific cluster should probably include the Cluster as a logging key (which may be easier to plumb through in some circumstances than others).

[aestriplex]

Hi @alecgrieser, I was implementing this patch. I'll start with the three examples you gave in your issue by adding a .detail(...) with the cluster. I was thinking how I could make the cluster data entry clearer in the future. What about creating a derived class for the client's TraceEvent, which simply wraps the TraceEvent class, exposing a constructor that also takes a string for the cluster (cluster name, id or connection)?

[alecgrieser]

Yeah, I could see something like that being useful, though I'm not an authority on what guidelines the core server team like to follow with stuff like this. I could also see some kind of "logger context" being used for adding default context in cases like this, but I'm not sure what the best way to manage that context in the realm of FDB server would be