Update sign and send response payload

Currently sign_and_send_tranasactions returns a list of signatures for the signed payloads. This gets messy in a multi-account world where a single transaction payload might require multiple signatures from the wallet.

For example: If a dapp requests 2 transactions to be signed and sent, where the first payload requires 2 signatures from the wallet, and the second transaction requires 1 signature from the wallet, 3 signatures will be need to be returned. What is the expected order of those signatures? Right now I am operating under the assumption that the signatures will be returned in this order: [ "transaction1_signature1", "transaction1_signature2", "transaction2_signature1" ]. However, this means that the returned list of signatures will have a different length than the number of requested payloads.

The alternative would be to concatenate the signatures for each transaction, so in this example the returned signatures would be [ "transaction1_signature1+transaction1_signature2", "transaction2_signature1" ]. this keeps the array lengths consistent but introduces dependency on the signature length, which could get messy for multichain. I am leaning towards the former.

This why I am proposing that we change the response over to signed_payloads, like we do in sign_transactions. We should be able to automatically handle both backward and forward compatibility at the SDK level (automatically filling the 'signatures` array if its not present, and vice versa).

solana-mobile / mobile-wallet-adapter

Update sign and send response payload #774