Or of two RunContainers can produce an under-sized BitmapContainer

[larsk-db]

Describe the bug
There is a very niche edge case, where or:ing two RunContainers can produce a BitmapContainer that is actually undersized, because it happens to serialize more efficiently than the resulting RunContainer. This container works perfectly fine in memory, but as soon as it gets serialized and we then try to deserialize it again, we will try to read the bytes as if they were of an ArrayContainer, because we determine this by cardinality. And obviously the result is garbage :D (if it doesn't just flat out fail during deserialization, which is what we originally observed).

To Reproduce
This is a bit of a pathological example that highlights the issue is possible. But we have observed it in real bitmaps that were created with the high-level APIs, not container level. They are just a bit too large to use as a test case for the library, so I hope the pathological example below will serve.

@Test
public void or6() {
  System.out.println("or6");
  RunContainer rc1 = new RunContainer();
  for (int i = 0; i < 6144; i += 6) {
    rc1.iadd(i, i+1);
  }

  RunContainer rc2 = new RunContainer();

  for (int i = 3; i < 6144; i += 6) {
    rc2.iadd(i, i+1);
  }

  Container result = rc1.or(rc2);
  assertTrue(result.getCardinality() < ArrayContainer.DEFAULT_MAX_SIZE);
  assertTrue(result instanceof ArrayContainer);
}

RoaringBitmap version: 1.0.6-SNAPSHOT
I.e. I tested this on latest master.

Java version: openjdk version "11.0.12" 2021-07-20 LTS

Fix
I already have a fix and will post a PR with test and fix soon.

[lemire]

Thanks. This is a very serious issue. Very glad for the report.