[dbnode] Fix the insertion of entries in shard entry list to maintain strictly increasing order of unique index

[RiyaTyagi]

What this PR does / why we need it:
This PR fixes the logic to insert the entries in shard entry list to maintain the strictly increasing order of entry's unique index added to the list. This will fix the issue of skipping few series IDs while fetching the block metadata for peer bootstrapping.
During peer bootstrapping the dbnode fetches the series metadata from peers via FetchBlocksMetadataRawV2 call. The pagination logic for this call is based on the assumption that entries are added in a strictly increasing order of entry's unique index to the shard list. While debugging the issue of data loss during peer bootstrapping it was found that some of the entries are not added in this order. This causes some of the series Ids to be skipped during peer bootstrapping which in turn results in data loss if a particular series id is skipped by every peer.

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing and/or backwards incompatible change?:

NONE

Does this PR require updating code package or user-facing documentation?:

NONE

[CLAassistant]

All committers have signed the CLA.

[linasm]

@RiyaTyagi could you try seeing whether #4263 would actually solve the pagination issue during peer bootstrapping?

[prateek]

please add tests we talked about

• unit test from Arnav's internal diff
• integration test replicating the issue

[RiyaTyagi]

I have benchmarked the two PRs against the current m3db version on a 3 node cluster and here are the results:

Current Version Memory usage:

Memory usage for the current PR with sorting logic:

Memory usage for the other PR with extra entry field:

[prateek]

lgtm

[prateek]

@linasm ta for the suggestion, Riya ended up using the solution from the other PR