feat(pdp): add idempotency to create and add handlers

[Kubuxu]

Introduces a IdempotencyKey to JSON paylods of these handlers, which
deboounces requests and if the request with the same key completed,
redirects to the created resource.

Users should use UUIDs or ULIDs as their IdempotencyKey-s

[Kubuxu]

I still need to test it on my curio but should be good for review.

[rvagg]

@Kubuxu can you walk me through an example of how this will be used and will be useful? Are you imagining the bad-network case where an app can re-push the same thing? But who holds on to the idempotency key such that retries would use the same key? Or are you imagining that being something that the SDK could generate and it be stable across some set of similar-enough calls? Cause right now, each call to create or add ends up making a unique nonce deep inside the SDK, so the client doesn't have the opportunity to do an identical retry.

[Kubuxu]

Yeah, I was going to create a more expansive issue for this.
I'm mainly targeting the "bad network" case. We tried sending a request, but didn't get a response back for some reason. It will allow us to retry the same request without triggering side effects if the first request was received, but we failed to receive a response.
The key is generated on the client side and reused if the request is equivalent to one that has already been sent.
It can be "the request didn't go through due to network issues" or "application crashed between the steps of sending the request and saving the transaction hash" (if we were going for very strict transactionality on the client side).

This should be an implementation detail ideally not exposed to the end user. In my initial stab at this, I was considering using the extra data payload as the key, but this is less constraining. @hugomrdias might have more ideas on how to utilise it effectively within Synapse, as this is something we discussed back when we met.

[hugomrdias]

yep mostly what kuba said, resume from crashes.

[BigLep]

I think we need to back up here and do some of the "lightweight" design we discussed in Buenos Aires as we move from sprinting to march. Assuming we do this work, it at least touches Synpase, Curio, and Docs. Lets quickly plan this out accordingly and determine whether this is even in scope for GA. Issue for the lightweight design is FilOzone/synapse-sdk#479

I'm converting this to draft until we have had some of the discussion in FilOzone/synapse-sdk#479