[service-bus] Batch receiving

[richardpark-msft]

Batch receiving is receiving messages with a finite limit. This differs from streaming in that you should be able to request 5 messages and get no more than 5 messages.

In JS they also drain the link after the receive so no excess messages or internal cache is required, which removes a whole class of potential problems.

Both of these are not implemented in the go-amqp library today. You are always forced to create a link with rolling credits turned on and cannot adjust it after the link has been created.

The typical use case for this kind of API is a set of workers that come up, process a message, and then die (for instance, workers in a build system).

The usage would be similar to this:

// NOTE: context.WithTimeout() is probably more 'go' appropriate for the timeout.
messages, err := receiver.ReceiveMessages(ctx, 5, timeout)

if err != nil {
  // elided
}

for _, message := range messages {
  receiver.CompleteMessage(ctx, message)
}

As referenced in: #15092
(AMQP work should be included as part of #14907)

[richardpark-msft]

Fixed as of #15480

[richardpark-msft]

Fixed as of #15480