Request reply baseline benchmark

[mtmk]

Request reply performance improvements: The basic idea is to create a shortcut to avoid additional subscriber (albeit muxed) creation so that we can save on additional allocations and potentially work. reply many can stay the same since creating a subscriber makes sense there.

This is a baseline benchmark we can merge now so that when the actual performance work is done we can have an easy way to compare results:

Method	Mean	Error	StdDev	Allocated
RequestReplyAsync	217.4 us	41.71 us	2.29 us	3.68 KB

• see also JetStream publish performance #450

[stebet]

@mtmk One thing I did in my app that uses the v2 lib is to not use the built-in request-reply since it creates a new subscription for every request. I just use one subscription generating a random prefix (inbox if you will) and then reuse that subscription for all requests, appending a unique ID to the prefix, f.ex:
_somerandominboxid.randomrequestid.

That way my custom subscriber just has to have one active long-running ephemeral subscription to get each response for _somerandominboxid.*.

It performs a lot better than the built-in request-reply mechanism.

Is there a reason it currently creates a new subscription each time?

[mtmk]

@stebet what you're doing is sensible and we should handle it more efficiently in the library. It's not as bad at the moment since we are using a 'mux' inbox as you described, but still creating somewhat a dummy 'inbox subscription' object to handle it. So the communication with the server is optimal but internal handling still a bit costly.

The reason for this approach is to generalize mux subscriptions so application code can leverage that too. e.g. if you create a subscription with the current inbox prefix, that would not create a new subscription on the server. However, this is not documented and I'm not sure if it's used at all.

So the idea in this PR to make a special case for Request-Reply since it's a very common pattern (especially when using JetStream for example) and improve its 'internal' performance. Any ideas, critique welcome, as always.

[mtmk]

keeping this PR simple to a benchmark only.