Add support for Message Queue java clients

[Xylus]

Adding message queue support requires a new type of node handling. While it is similar to how nodes are generated from ServiceTypeProperty.TERMINAL and ServiceTypeCategory.RPC typed span events, a message queue node differs from the former in that transactions may continue after the generated node, and from the latter in that the target node comes one depth after the generated node.
Thus in order to handle this, a new ServiceTypeProperty will be introduced named QUEUE.

Message queue plugins that defines a ServiceType with the QUEUE property should meet the following conditions:

1. Producer span event must be able to provide enough information to generate the target queue node
2. Consumer span must be able to have enough information to generate it's source queue node
3. The source/target queue node from above must be identical if they are part of the same transaction

In order to satisfy above, we should set the destinationId of the producer's span event, and the acceptorHost of the consumer's span to the same value - the queue name being a strong possibility. Other attributes such as endPoint or remoteAddress should remain the same as other RPC client plugins.
There should also be a way for the producer to send trace headers over the wire to the consumer (similar to trace headers injected into HTTP header for HTTP clients).

Once the message queue client plugin is set, the rest is up to the collector/web. There are 2 main areas to look at:

1. Server map (constructed using call statistics)
2. Transaction view (constructed using actual trace data)

Current plan is to generate extra call statistics for the virtual queue node at the collector level for the main server map, and to add extra logic to handle queues for the trasaction view.

Current limitations

• Our trace data model currently does not support single producer / multiple consumer messages (such as when broadcasting messages). These will show up correctly in the server map, but the call stack will only show a single consumer span. Multiple producer / single consumer (batch processing?) messages will manifest themselves similarly only reversed. These issues must be addressed with the planned Trace table overhaul.
• With the changes made to rowkey for TraceV2 table, and fixes introduced in Shows all the Consumers derived from the request #5807, multiple consumer traces now show up properly in the call stack (unless multiple consumers were listening from the same application - so 1 consumer trace per agent).

[nstopkimsk]

👍