Log current backoff in WaitingForMoreMessages

[davidmrdavid]

In some recent performance-sensitive investigations, I've found it challenging not to have access to the current queue-polling backOff whenever a WaitingForMoreMessages delay takes place. I think it would be nice to include this in our logs, so that we're armed with precise data on how much latency is expected between MessageReceived operations (assuming the queue is populated).

[cgillum]

I think there's a slight misunderstanding here. We only log WaitingForMoreMessages once until more messages arrive. We don't log it repeatedly, which I think this PR assumes. Otherwise, we'd be spamming the logs with polling messages when the app is idle, which we don't want to do for informational messages.

If you want to monitor the polling delay, then I suggest introducing a new debug-level log.