DenseSet::Grow optimization

[BorysTheDev]

fixes: #3870

Before BM_Grow 721975 ns 721914 ns 1020
Now BM_Grow 598066 ns 597285 ns 1237

[romange]

TLDR: on my machine, the original code:

M_Grow       7003864 ns      7003556 ns          795

This PR:

BM_Grow       7088574 ns      7088288 ns          785

In more detail:

1. Benchmark. I found this one to be more robust. The reason - Fill() is more efficient than AddMany.
   In addition, adding an element at size 2^k does not guarantee trigerring resize so I added explicit checks to make sure.

void BM_Grow(benchmark::State& state) {
  vector<string> strs;
  mt19937 generator(0);
  StringSet src;
  unsigned elems = 1 << 18;
  for (size_t i = 0; i < elems; ++i) {
    src.Add(random_string(generator, 16), UINT32_MAX);
    strs.push_back(random_string(generator, 16));
  }

  while (state.KeepRunning()) {
    state.PauseTiming();
    StringSet tmp;
    src.Fill(&tmp);
    CHECK_EQ(tmp.BucketCount(), elems);
    state.ResumeTiming();
    for (const auto& str : strs) {
      tmp.Add(str);
      if (tmp.BucketCount() > elems) {
        break;  // we grew
      }
    }

    CHECK_GT(tmp.BucketCount(), elems);
  }
}
BENCHMARK(BM_Grow);

2. I actually tried to optimize as well and I got even worse results than this PR. I must say the base line of Grow is already very good but I would like some more time to analyze this.

[romange]

And I still think that cached links is unnecessary over complication.

[BorysTheDev]

And I still think that cached links is unnecessary over complication.

We already use FreeLink and NewLink, we can create a small class that incapsulate this logic and cached links. it's very smooth and really good for performance even for ADD/REM operations