Comment 5 for bug 1736911

I like the idea of having a userTag in pvAccess, the question is how do we make use of it?
Currently, it's up to EPICS engineers to make sure the userTag gets updated when needed.
Even if we make our drivers V4 aware, it only allows setting userTags in those specific V4
objects. It doesn't allow modules like pvaSrv or pva2pva to set the userTag appropriately
when publishing dbRecord's via pvAccess.

Most of the approaches we've been considering involve trying to add userTags to the db and
propagate them via TSEL or TSE mechanisms. What if we stop trying to add a userTag to the
record database since we can't easily add it to CA, and instead just provide a way for site's
to determine how pvData userTag's get set and propagate.

What I like about adding a userTagProvider() API is that it wouldn't affect modules like asyn that just interface w/ the dbCore API. Since the userTag was added in pvData and the other V4 modules, we just need to make sure those modules call the userTagProvider() whenever they update the pvData::TimeStamp.

As to the API, SLAC would just need the timeStamp to derive the userTag, but I think we could
provide an API that would provide some options for other userTag use cases.

We'd also be ok w/ a signed 64 bit userId as we could easily wrap it to unsigned,
and I think a signed integer would provide more options for site specific userTags.

How about this for the API of a userTag provider callback?
Caller can pass NULL for any parameters which aren't available and the
userTag provider can determine the policy for how to set the userTag given the available info.

typedef epicsInt64 (* USERTAGFUN)( const epicsTimeStamp * pTimeStamp, const dbCommon * pRec, const epicsInt64 * pUserTag );