WIP: Make BitBox Sync + Send

[edouardparis]

introduce a new build feature that change the ReadWrite async trait. I quite busy right now, I will try to describe the rationals more clearly later.

[edouardparis]

Why do you need to make ReadWrite a new generic param?

I agree that in my quest to create a sync + send Bitbox, this change was may be not required. What do you think I create a new PR that:

• change ReadWrite as Send by default and makes it async_trait(?Send) if wasm feature is enabled
• remove RefCell and add Arc Mutex over PairedBitbox to make Bitbox Sync.

An async interface that can be send to thread is useful for clients that have multiple thread running and do not want their main thread to be waiting for the end of the signing process for example. Mutex are not a performance issue because communication with device is already blocking with the user confirmation (only one screen).

[benma]

An async interface that can be send to thread is useful for clients that have multiple thread running and do not want their main thread to be waiting for the end of the signing process for example.

I am not sure I see the connection - it is async after all, so nothing should be blocked even in the main thread. Also, the object could be created in another thread but kept there.

The reason I am a bit hesitant is that on macOS, we've seen issues if the hidapi calls are not fixed to one thread. See https://github.com/libusb/hidapi/issues/503. We never could figure out the root cause of that issue, but it may appear if one moves the PairedBitBox object between threads. If possible, it would be better to just spawn it in a separate thread and keep it there - there should be no problem with blocking as everything is async anyway.

Would that work? If not, why not?

[edouardparis]

deprecated in favor of #17