use max-heap to collect shink candidates by byte savings

[HaoranYi]

Problem

1. selecting storage to shink by alive ratio may not improve the alive ratio as much as by byte savings.

For example, given two storages below:
Storage A: alive = 1, total = 2, alive ratio = 0.5
Storage B: alive = 6, total = 10, alive ratio = 0.6

If we select by ratio, then A will be chosen to shrink, which gives result ratio of 7/11 (0.63).
However, if we select by bytes savings, B will be chosen. This gives the result ratio of 7/8 (0.875).

2. When collecting candidate storages for shrinking, we don't need to sort all the
   storages. We could just partially sort the storages before the cutoff (i.e. use a heap).

Summary of Changes

Use max-heap to store and partially sort and select candidate storage for shrinking by bye savings.

Fixes #

[codecov]

Codecov Report

Merging #33731 (402d9c0) into master (673a38c) will increase coverage by 0.0%.
Report is 26 commits behind head on master.
The diff coverage is 96.4%.

@@           Coverage Diff           @@
##           master   #33731   +/-   ##
=======================================
  Coverage    81.8%    81.8%           
=======================================
  Files         806      806           
  Lines      217859   217923   +64     
=======================================
+ Hits       178239   178296   +57     
- Misses      39620    39627    +7     

[brooksprumo]

How are the performance numbers, before and after?

[HaoranYi]

How are the performance numbers, before and after?

looks like there is not much performance difference (red: master (#33739), blue: this pr).

[brooksprumo]

Seems reasonable to me, just one nit.

[brooksprumo]

Looks good. One nit/question.

[brooksprumo]

How do the byte savings look on mnb and/or pop-net?

[HaoranYi]

How do the byte savings look on mnb and/or pop-net?

comparison of mnb run from last night shows not much difference.

blue: this pr
red: master