Make PreparedSend cloneable

[ok300]

Description

This PR makes PreparedSend cloneable. This is useful for callers when handling the send cancellation, which may happen in a context that only has a &PreparedSend.

---

Checklist

• I followed the code style guidelines
• I ran just final-check before committing

[thesimplekid]

#596 (comment)

[ok300]

I don't know if this is a good defense against the flow you mentioned.

For example, when this will be exposed via bindings, there is no way to enforce the same rust-specific ownership protections in let's say javascript. So it's safe to assume at least some callers will be able to clone with no problem.

IMO the more robust way is to make this cloneable (since we cannot reliably forbid it) and rely on a different mechanism to avoid prepare_send -> send -> cancel_send. The comment you linked says such mechanisms were already added to that PR.

[davidcaseria]

What is the use case for which Clone is needed?

Because JavaScript users can do something dangerous, we should allow Rust users to do something dangerous isn't a compelling reason to allow this, imo.

[ok300]

Most apps are multi-threaded (UI thread, background threads), so they pass data either by reference with Arc or by cloning. The place calling prepare_send might well be a different thread or context than the one calling send, since prepare_send might involve asking for user confirmation. IIRC this was the main argument for the current Prepare Send architecture, namely that in some apps different threads could try to send or swap at the same time, like bots or automated tools.

So it's therefore natural that callers will try to either

1. use PreparedSend as a reference, which won't work because send and cancel_send take ownership, or
2. clone PreparedSend when passing it to the thread or context that consumes it, which won't work because its not cloneable.

If that's not possible, they'll have to

3. rework their app internals to allow passing ownership of PreparedSend (for rust, that's channels or an Arc<Mutex<>>)

In rust, callers can be blocked from the first 2 options and essentially forced to use the 3rd.

But CDK is planning to add bindings. Do you know for sure which languages will be covered by the bindings? Will those users be doing something "dangerous" if they try to clone an object or use it as reference, which they already do in the rest of their app? Is the CDK team prepared to 1) document why this shouldn't be attempted, 2) keep an eye out for all future binding languages and make sure the exposed PreparedSend is not cloneable in that language?

Seems to me a bit unfair to callers, and not a very robust way forward for CDK.

Since we can't reliably forbid it, we should allow cloning and instead rely on CDK-internal mechanisms to handle the prepare / send / cancel_send flow.

[davidcaseria]

I haven't encountered this issue when building CDK-Flutter using a widget or the Wallet Rust struct and Dart class.

If someone needed to use a prepared send across multiple threads, although I can't think of a reason why anyone would do that, using a Mutex seems reasonable to me to avoid trying to process a send twice.