[Bug] key_shared consumer with backlog cause pulsar broker read a huge amount data from bookkeeper but dispatch a little, cause network bandwith exhausted

### Search before asking

- [X] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.

### Read release policy

- [X] I understand that unsupported versions don't get bug fixes. I will attempt to reproduce the issue on a supported version of Pulsar client and Pulsar broker.

### Version

linux x64, java17, pulsar 3.0.4, pulsar c++ client 3.4.2

### Minimal reproduce step

1. stop key_shared consumer 5 mininutes
2. start key_shared consumer

### What did you expect to see?

1. broker the data dispatch to consumer is closely to the the data read speed from bookie
2. consumer can finish read backlog after a couple of minutes

### What did you see instead?

1. broker read a lot of data from bookkeeper only dispatch a little

the node with only broker: it‘s network receive is very big, but only transmit a little data to consumer

the node with only bookeeper: it‘s network transmit is 23Gb/s, network band with reach the hardware limit ;

2. consumer can not catch up;

### Anything else?

the bookkeeper disk read is very low; so the data is in the bookkeeper read cache; I think maybe some bug cause pulsar broker keep read same entry from bookkeeper , cause the network bandwith exhausted

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!

Reproduce the issue by stopping a key_shared consumer for five minutes and restarting it on the reported Pulsar 3.0.4 and C++ client 3.4.2 versions. Compare broker-to-bookkeeper reads with consumer dispatch and backlog recovery; done means the broker no longer reads substantially more data than it dispatches and the consumer catches up without exhausting network bandwidth.

Written by the indexing model from the issue text.