Anti-spam support

[AlCutter]

Description

Tessera should support a best-effort deduplication mechanism which may optionally be used to help mitigate the effects of abuse.

Ideally, we'll have idiomatic/native drivers for the storage infrastructure Tessera currently supports, but also provide the ability for users of the Tessera library to implement their own dedupe drivers.

Strong/atomic/transactional deduplication is explicitly out of scope. We have previously found this to be expensive in cost & throughput, and would restrict the types of storage infrastructure Tessera could support. This goes against the philosophy of the Tessera approach.

[patflynn]

I like this framing of the dedupe work because it helps me reason about what solution is good enough to address the spam risk. I'd love to see some concrete spam risks from a small set of personality implementations to help understand what their common needs are.

@phbnf what do you think about using this framing and documenting spam risks for CT as the parent FR for CT dedupe?