Add multi-sig support

[DOBEN]

Purpose

Addresses #296
Related Concordium/concordium-base#529

The following transaction types were tested using multi-sig:

• DeployModule, InitContract, Update, Transfer, TransferWithMemo, TransferWithScheduleAndMemo, TransferWithSchedule, ConfigureDelegation, ConfigureBaker, RegisterData, UpdateCredentialKeys, and UpdateCredentials .

The following transaction types were NOT tested using multi-sig:

• AddBaker, RemoveBaker , UpdateBakerStake, UpdateBakerRestakeEarnings, and UpdateBakerKeys (concordium-client created these types in protocol versions below Types.P4 but not anymore).
  https://github.com/Concordium/concordium-client/blob/main/src/Concordium/Client/Runner.hs#L3698
• UpdateCredentials (access to ledger + desktop wallet is required for creating a valid credential file - postponed/blocked but planned to be tested later)

Update: it was tested by now

• TransferToEncrypted, TransferToPublic, EncryptedAmountTransfer and EncryptedAmountTransferWithMemo
  (shielded transactions are faced out and the feature will be removed, so the multi-sig feature will not be tested/implemented for it).

How to test this PR:

Use these two guides to create a multi-sig account.
https://gist.github.com/DOBEN/683fe1a7c82a0551546a7ec242d30cc0
https://gist.github.com/limemloh/8c0c55f67cf5a83ac7cc21cb646e65c1

There are two main steps to complete:

• Execute an update-key transaction on-chain to associate an additional key to your credential/account + set the key threshold to 2 (alternatively you can also add an additional credential with some keys)

concordium-client account update-keys --credId 97f325c...722454df --sender 4jxvYasaPncfmCFCLZCvuL5cZuvR5HAQezCHZH7ZA7AGsRYpix ./update-keys.json  --grpc-port 20000 --grpc-ip node.testnet.concordium.com

• Configure concordium-client to locally have access to these two keys.

concordium-client config account update-keys --keys KEYFILE --account 4jxvYasaPncfmCFCLZCvuL5cZuvR5HAQezCHZH7ZA7AGsRYpix 

Example transaction flow:

1. Step: Create a ContractUpdate transaction - Sign it with one key - Dump the partially-signed transaction into a transaction.json file:

stack run concordium-client -- contract update 3383 --signers "0:0" --entrypoint updateOperator --outFile ./transaction.json --parameter-json updateOperator.json --energy 5000 --sender 4jxvYasaPncfmCFCLZCvuL5cZuvR5HAQezCHZH7ZA7AGsRYpix --grpc-port 20000 --grpc-ip node.testnet.concordium.com

2. Step: Add an additional signature

stack run concordium-client -- transaction add-signature ./transaction.json --signers "0:1" --grpc-port 20000 --grpc-ip node.testnet.concordium.com

3. Step: Send the fully signed transaction on-chain

stack run concordium-client -- transaction submit ./transaction.json  --grpc-port 20000 --grpc-ip node.testnet.concordium.com

4. Alternative Step: Pass in a key file when signing instead of using local keys:

stack run concordium-client -- transaction add-signature ./transaction.json --keys ../keypair1.json --grpc-port 20000 --grpc-ip node.testnet.concordium.com

Changes

• Rename subcommand TransactionSubmit to TransactionSignAndSubmit (keep its functionality)

• Create two new subcommands:

  • TransactionSubmit
  • TransactionAddSignature

• Add optional --out flag to all transaction-creating commands.

[eb-concordium]

Looks good :)
Regarding UpdateCredentials, I do not agree that access to ledger + desktop wallet is required for creating a valid credential file. You can do that with the tool client in concordium-base/rust-bins/src/bin/ :)

[td202]

Looks good. I think it would be nice for submitting transactions to have better error handling (or perhaps checking before-hand) for the transaction having insufficient signatures or having already expired.

I also wonder if we can just completely remove the "sign-and-submit" behaviour. Part of the problem with it is that it uses a different format from "submit" and the other transaction commands, so it could cause issues for people.

It could also be nice to have an easy way to create a transaction without signing at all. (It is possible by specifying a file with contents {} to the --keys, so I don't think this is essential to add.)

[DOBEN]

Looks good. I think it would be nice for submitting transactions to have better error handling (or perhaps checking before-hand) for the transaction having insufficient signatures or having already expired.

I also wonder if we can just completely remove the "sign-and-submit" behaviour. Part of the problem with it is that it uses a different format from "submit" and the other transaction commands, so it could cause issues for people.

It could also be nice to have an easy way to create a transaction without signing at all. (It is possible by specifying a file with contents {} to the --keys, so I don't think this is essential to add.)

Great input:

I created an extra issue for checking for enough signatures since this behavior is already present and should be improved for regular transaction (not loaded from a partially signed transaction JSON file) as well.
#305

I added checks for the expiredTimestamp in this PR.

Yes, we should remove the signAndSubmit command in my opinion as well:
#306

I will add to the developer documentation your hack on creating a partially-signed transaction file without signing it with any keys. This can be useful if one tech-savvy person prepares the file but other people need to sign it.