[dbnode] Use bits.LeadingZeros64 to improve encoder performance

[linasm]

What this PR does / why we need it:
Improves M3TSZ encoder performance by using bits.LeadingZeros64 instead of custom loop code (up to 64 iterations) to count significant bits. The result is ~12% performance improvement (and a simpler code).

Before the change:
BenchmarkM3TSZEncode-12 8128 139077 ns/op

After the change:
BenchmarkM3TSZEncode-12 9357 123138 ns/op

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

[robskillington]

Nice. This seems like a good win, have looked at bits.TrailingZeros64 for the new roaring bitmap query side rewrite (from PR #2791):

m3/src/m3ninx/postings/roaring/bitmap_readonly.go

Line 489 in 7a2683a

firstBitSet := uint64(bits.TrailingZeros64(i.containerState.bitmapCurr))

How representative do you think the benchmark is? Can we expect most encoder performance gains to be able to be measured by this micro benchmark?

[robskillington]

LGTM

[codecov]

Codecov Report

Merging #2857 (4071759) into master (4071759) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #2857   +/-   ##
======================================
  Coverage    72.1%   72.1%           
======================================
  Files        1099    1099           
  Lines       99811   99811           
======================================
  Hits        71982   71982           
  Misses      22892   22892           
  Partials     4937    4937           

Flag	Coverage Δ
aggregator	75.9% <0.0%> (ø)
cluster	84.9% <0.0%> (ø)
collector	84.3% <0.0%> (ø)
dbnode	79.2% <0.0%> (ø)
m3em	74.4% <0.0%> (ø)
m3ninx	73.2% <0.0%> (ø)
metrics	17.2% <0.0%> (ø)
msg	74.2% <0.0%> (ø)
query	68.9% <0.0%> (ø)
x	80.3% <0.0%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4071759...f634274. Read the comment docs.

[linasm]

How representative do you think the benchmark is? Can we expect most encoder performance gains to be able to be measured by this micro benchmark?

I've picked somewhat randomly 10 series from some real-world data file that I had (this is the same data that I used in #2827).
It should be representative enough at least for measuring general improvements that do not try to take advantage of specific properties of the encoded data (eg. on having long series of constant values). I think these benchmarks should be useful for further optimization effort, either as is, or by adding more data samples to them.