Azure Service Bus sessions: ordered handling per key #358

Context

Follow-up from #346 / #357, which added @node-ts/bus-azure-service-bus without sessions.

Azure Service Bus sessions give ordered, one-at-a-time handling of the messages that share a session id. For example, all events for one order are handled in the order they were sent, by one receiver at a time, while other orders are handled in parallel.

Problem

The transport's topology can't use sessions as it is:

• Each message is sent to its own topic, and a subscription per handling endpoint auto-forwards (forwardTo) into the endpoint's queue.
• A queue or subscription with sessions turned on can't be the source of auto-forwarding. Setting ForwardTo on a session-enabled entity fails.
• Forwarding into a session-enabled queue is allowed, but a forwarded message without a session id is dead-lettered.

So ordered handling needs a different topology, for example:

• endpoints that read session-enabled subscriptions directly instead of one forwarded queue, meaning one receiver per handled topic;
• or a session-enabled endpoint queue that every message reaches with a session id.

Open questions

• How a sender sets the session id: a message attribute, a resolver per message type, or a sticky attribute.
• How sessions fit the bus' concurrency and its readNextMessage() loop, since session receivers lock a session rather than single messages.
• How retries work. The transport schedules a copy at now + delay, which would put the copy behind later messages in the same session and break their order.
• How dead-lettering works.
• What provision() creates, and what the runtime plan needs.
• Whether the emulator supports what the tests need. It supports RequiresSession.

Non-goals

• Sessions on other transports.