3.16: More/better TPRO context data

[Andrew Johnson]

In 3.15 and later, setting TPRO results in dbAccess calling dbServerClient() to obtain printable information about the thread that is causing processing to occur. This calls each registered dbServer in turn asking it to provide context data if it is responsible for the current thread (rsrv responds with "ca:<username>@<host>"). It should be possible to improve the information available so that scanOnce() and maybe other queues don't lose the triggering context.

If the scanOnce subsystem registered as a dbServer, when it gets asked to queue a record with TPRO set it could call dbServerClient() and save the context information from its caller along with the record, then respond with that data when its dbServer::client() routine is called by dbAccess from within the onceTask.

scanOnce is used by dbCa to process records with CP and CPP links when their monitors fire. The dbCa task would also have to register as a dbServer so it could provide the necessary information (this would require a threadPrivate variable, scanLinkOnce() is run from the CA client callback routines), or we could add an alternative API to scanOnceCallback() which provides the context information to be queued (no threadPrivate variable needed, but less flexible). This context data should only be stored when TPRO is set though, we shouldn't be allocating memory and generating the context string unnecessarily.