TxLock and finalize

[quentinlesceller]

Past behavior of the init_send_tx method with InitSendTxArgs (only when the recipient wallet was reachable):

1. Sender sends transaction to recipient
2. Recipients receives it and send back
3. Sender lock outputs
4. Sender finalise iff InitSendTxArgs contains finalize=true and returns the final slate
5. Sender post_tx iff InitSendTxArgs contains post_tx=true and returns the final slate

Current behavior with the same condition:

1. Sender sends transaction to recipient
2. Recipients receives it and send back
3. A. If post_tx=true Sender lock outputs, finalize and post_tx iff post_tx=true and returns the final slate
4. B. If post_tx=false Sender returns the first slate

This PR locks outputs, finalise and return the final transaction but do not post when post_tx=false.

Fixes #480.

Might not be the best solution though. Thoughts @yeastplume ?

[yeastplume]

All looks fine, thanks for looking into this. You think it's worth cherry-picking to 4.0.x as well?

[quentinlesceller]

Do you think that'll be more logical to do something else like:

• init_send_tx when InitSendTxArgs is present should finalize by default and retrieve the S3 transaction. (this PR)
• init_send_tx when InitSendTxArgs is present should returns the S2 transaction. The user will then "manually" call finalize on it and post.
• init_sed_tx reintroduce the finalize arg in InitSendTxArgs and returns S2 if finalize=false and S3 if finalize=true

[yeastplume]

The send args are in place to emulate the wallet send command as closely as possible, so the idea was that if they're present, the command attempt to send, retrieve the S3 result and finalize in one call. So current behavior in this PR is consistent with how it's been working to date

[quentinlesceller]

Also this is worth cherry picking into v4.0.x branch. Missed it somehow