RedeliveryCount is 0 on redelivery

**Describe the bug**
I have a pulsar server with a single topic and a message produced to the topic.
It is a standalone server.
I have a client app having a single consumer.
Subscription type is Shared.
When I receive the message, and then stop the client app before ack-ing, and then start the client app again, then the message is redelivered as expected, but with redeliveryCount=0 (expected 1).
Similarily, when the consumer reconnects due to temporary lack of connectivity to pulsar server before ack-ing, then the redelivered message has the redeliveryCount=0.

**To Reproduce**
Steps to reproduce the behavior:
1. Receive a message.
2. Block connectivity. I did it like this:
`sudo iptables -I INPUT -p tcp -m tcp --dport 6650 -j REJECT`
3. Acknowledge the message while there's no connectivity
4. Wait longer than ping timeout (keepaliveIntervalMillis?, default is 30sec.)
5. Unblock connectivity:
`sudo iptables -D INPUT -p tcp -m tcp --dport 6650 -j REJECT`
6. Reconnect will occur and message will be redelivered (as expected), but, it's redeliveryCount will be 0 (not 1).

OR:
1. Receive a message.
2. Stop the client app without ack-ing the message.
3. Start client app again.
4. Redelivery occurs with redeliveryCount=0.

**Expected behavior**
Redelivered message's redeliveryCount value should be 1 instead of 0.

**Desktop (please complete the following information):**
- OS: Ubuntu 18
- Using Java pulsar client.

Start with the Java Pulsar client and reproduce the Shared-subscription flow described: receive without acknowledging, disconnect or stop the client, then reconnect. Inspect how redelivery metadata is restored across reconnects. Done means the redelivered message reports redeliveryCount=1 in both scenarios.

Written by the indexing model from the issue text.