Multiple creations of the same data across a partitioned network results in repeat results in query APIs

[pospi]

I think this is partially an issue with anchored_record_helpers.rs, but it's only possible to de-duplicate this optimistically for now. (further work needed on reads to resolve duplicate writes of the same data in re-synced network partitions).

[pospi]

This issue mostly only affects Unit records, since the majority of other record types are considered unique in the moment they're created via the addition of some randomBytes() in an internal nonce field.

Now resolved for writes- a sychronised network will no longer unnecessarily add create Action headers. Reopening as an issue to resolve generically for reads of "idempotently unique" data (ie. data with a manually defined retrieval key) which has been duplicated as a result of a network partition or partial sync.

Aside from behaviour in hdk_records/src/anchored_record_helpers.rs this also affects indexing retrieval logic in hdk_semantic_indexes and hdk_time_indexing. At minimum, any feature which depends on link_if_not_linked in the write phase to ensure uniqueness, also must be able to de-duplicate accidental repeat writes in its associated read phase.

There may be other elements to consider in a complete solution, and platform features such as 'bucketing' that could be leveraged to 'compact' data in this way in future versions of the Holochain hdi & hdk libs.

[pospi]

I have fixed issues with duplicate Unit record writes in an unpartitioned network in 589aeff. A single agent can no longer cause duplicate entries in the Units read API response by repeatedly writing the same record. This would have actually affected any content-addressable data written into a time index, but Unit is the only record type that operates this way (others have a nonce injected to force them to be unique, so recreating records will result in different hashes).

This does not resolve the issue for writes under partitioned network conditions, which still persists as above.