[Service Bus] isReceivingMessages on subscribe() output instead of receiver

[ramya-rao-a]

This is the current shape of the API for the Receiver in v7 of Service Bus:

export interface Receiver<ReceivedMessageT> {
    close(): Promise<void>;
    entityPath: string;
    getMessageIterator(options?: GetMessageIteratorOptions): AsyncIterableIterator<ReceivedMessageT>;
    isClosed: boolean;
    isReceivingMessages(): boolean;
    peekMessages(options?: PeekMessagesOptions): Promise<ReceivedMessage[]>;
    receiveDeferredMessages(sequenceNumbers: Long | Long[], options?: OperationOptions): Promise<ReceivedMessageT[]>;
    receiveMessages(maxMessages: number, options?: ReceiveMessagesOptions): Promise<ReceivedMessageT[]>;
    receiveMode: "peekLock" | "receiveAndDelete";
    subscribe(handlers: MessageHandlers<ReceivedMessageT>, options?: SubscribeOptions): void;
}

The isReceivingMessages() is mainly useful for the subscribe() model and not so much for the others

• It does not apply at all for peekMessages() and receiveDeferredMessages()
• receiveMessages() doesnt really need this as one can check the status of the promise returned by it to know if the receiving is done or not
• The iterator model does not need this as each loop can be awaited as well.

#9493 tracks the proposal to make subscribe() return a object that is closable.
This issue is to move the isReceivingMessages() into the above object.

Or at the very least, remove it from the Receiver and add it based on user feedback.

cc @richardpark-msft, @HarshaNalluru, @chradek

[ramya-rao-a]

Side note: In Event Hubs, we went with isRunning on the Subscription that was returned bu subscribe().
Not sure if that was meant for a purpose different than what isReceivingMessages() in Service Bus would serve

[chradek]

I think we went with isRunning to signify that the subscription wasn't closed, since technically the subscription might not be receiving events yet if it hasn't connected to any partitions. It's technically correct...

[richardpark-msft]

I'd talked with @ramya-rao-a about this - currently leaning towards removing it since it sounds like we added it because our receiver was unreliable (and this was a workaround for customers to detect that). There have been numerous reliability fixes in track 2 so removing this flag feels within reach.

[HarshaNalluru]

Done with #9875