chore: index with discoveryId not discoveryKey

[gmaclennan]

This reduces the crypto operations required during
indexing, which should increase indexing
performance.

Depends on:

• feat!: discoveryId instead of key for entries multi-core-indexer#25
• feat: decode with coreDiscoveryId as well as coreDiscoveryKey comapeo-schema#267

[RangerMauve]

Is this still relevant?

[gmaclennan]

Is this still relevant?

Yes, I believe it is. Currently the indexing pipeline calculates the discovery key (a Blake2b hash of the core key) twice for each document:

1. When decoding blocks in the index writer
2. When deriving the versionId to check for pending writes.

It is also calculated for each coreOwnership and deviceInfo record, but this is probably less of an impact because there are fewer of these.

Hashing, although fast, is not insignificant when done hundreds or thousands of times e.g. during indexing after an initial sync or project creation, and my hypothesis is that hash operations are significantly slower on older mobile devices without hardware crypto optimizations, although I don't have evidence for that yet!

Because during indexing in multi-core-indexer, the discovery key is already calculated for each core, and doesn't need to be calculated for each block/document, passing this through the indexing pipeline removes the need for these crypto opts.