[Broker] Preventing extra dispatch when entries will make permits negative

[devinbost]

I noticed that the broker currently does not consider the number of entries when determining if it should dispatch messages to the consumer. Due to the missing check, the broker can send more messages than available permits.
This PR prevents that from happening for persistent topics.

Related to #6054

[devinbost]

@rdhabalia @codelipenghui @merlimat @sijie Anything else I should add to this PR?

[merlimat]

The reason for this is that we want to avoid having to re-read messages again from storage. The number of permits going to negative is "fine", in the sense that the next round will adjust.

[devinbost]

@merlimat If the permits go negative when the subscription is stuck, then the approach by @rdhabalia to unblock the subscription won't work. See https://github.com/rdhabalia/pulsar/blob/df5195475edd2b6938849e7b2e5bc52aabad207d/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherSingleActiveConsumer.java#L587

[devinbost]

I'm closing this because there are a number of areas that expect permits to be <= 0 to control message flow, and this PR doesn't address the root issue behind subscriptions getting stuck.