feat: support cpcsketch serde

[tisonkun]

This closes #37

[tisonkun]

cc @PsiACE @Xuanwo @ZENOTME

[ZENOTME]

Does this mean that we should check the return value to prevent 0?

[tisonkun]

I suppose so.

cc @leerho I can't see similar requiremeny based on barely the Rust code. Could you provide more context why 0 is not allowed here?

[tisonkun]

BTW this comment is copied from computeSeedHash's Java version.

[leerho]

It is exactly what the comment says. It is to remain compatible with older sketch versions (in other languages) that did not have the concept of the seedHash. Once you have serialized a sketch, it no longer retains any information about what language generated the serialized image. That is the whole idea and quite powerful! Once you have properly created this sketch in Rust, you will be able to import sketch images created years ago from Java, C++, or whatever.

The fact that "older versions of Rust" don't have this problem is irrelevant. :)

And yes, the method that generates the seed must check for 0, as it does in Java.

And, hmmm, it looks like C++ doesn't check for zero either. Which is a bug.
The likely reason this has not been noticed before is because we always use the DEFAULT_UPDATE_SEED, which has a non-zero seed_hash.

[ZENOTME]

Look like we need to return an error here for the result is 0 as Java:

  public static short computeSeedHash(final long seed) {
    final long[] seedArr = {seed};
    final short seedHash = (short)(hash(seedArr, 0L)[0] & 0xFFFFL);
    if (seedHash == 0) {
      throw new SketchesArgumentException(
          "The given seed: " + seed + " produced a seedHash of zero. "
              + "You must choose a different seed.");
    }
    return seedHash;
  }

[tisonkun]

I'm going to do the following tasks after this patch is merged:

1. CpcWrapper to read fields without fully deserializing the sketch. This is implemented in the Java impl as well.
2. Investigate whether we need introspective_insertion_sort. Rust's slice sort should properly leverage existing ordered items already.

For this patch, one open question is whether to include the decoding table as static values, or build it at the first access (using OnceLock or so).

I tend to keep the static decoding tables. They should not increase the binary size too much.

[tisonkun]

I'm going to merge this patch now. Review after commit is welcome.

To reduce binary size, we'd follow #32 to exclude CpcSketch's code when users doesn't need it.