Change children hash function to XOR

[systream]

To improve the performance of the inserts, I have changed children hash function. With XOR not needed to recalculate the whole children hash, so it is 6-8 times faster and it does not break any test.

It is highly inspired what guys did in RIAK 3.0

[ferd]

Do you have a link to the Riak 3.0 work? I understand how this one should work, but it seems like a significant-enough change that I'd not trust my tests to actually be that good to uncover weird edges. If other people have done the analysis work, that'd be useful for me to read.

[systream]

They mention it in the documentation.
For example: https://github.com/martinsumner/kv_index_tictactree/blob/develop-3.0/docs/TICTAC.md#alternative-merkle-tree-tictac

The only scenario where I think it could be problems when hash collision occurs.
For example hash(K1), and hash(K2), hash(K3) returns the same result (let's call it Hash1).
Hash1 bxor Hash1 bxor Hash1 will return Hash1.
This could happen:
hash(K1) =:= hash(K1) bxor hash(K2) bxor hash(K3).

With the original hash([hash(K1), hash(K2), hash(K3)]) it will generates a different uniq hash.
hash([hash(K1)]) =/= hash([hash(K1), hash(K2), hash(K3)]),
but for example it may could happen hash([hash(k1)]) =:= hash([hash(k1), hash(k3)])

This same weird behaviour can happen (hash collision) with the leafs or also could happen when hashing the child's hashes. I thing the current implementation has almost the same probability of this kind of errors.

[ferd]

Makes sense. I'm likely to merge this, but will probably have to bump to a next major version since someone storing a serialized tree would see it break across versions.

[ferd]

MErged & Cut a new release, along with a hex publish. Thanks!