feat(multisig)!: pretty list of pending proposals

[s8sato]

Context

As of #5217 multisig has some defects especially around the recursion feature:

1. The output of multisig list command is verbose, not well structured, and less informative about the authentication status:

   Before

   "ed01201F89368A4F322263C6F1AEF156759A83FB1AD7D93BAA66BFDFA973ACBADA462F@wonderland"
   "1303a3f8222d9d5d687b8c787bdf6a90a7f774e54a8a37e52fb1681f69e05ba9"
   {
     "approvals": [
       "ed0120987EE8092B2CE4622B4F66D6FE87F5D61575F0D0DFCB2D6B2E8905FE68F685B6@wonderland"
     ],
     "expires_at_ms": 1731520010341,
     "instructions": [
       {
         "SetKeyValue": {
           "Account": {
             "key": "success_marker",
             "object": "ed01201F89368A4F322263C6F1AEF156759A83FB1AD7D93BAA66BFDFA973ACBADA462F@wonderland",
             "value": "congratulations"
           }
         }
       }
     ],
     "proposed_at_ms": 1731516410341
   }
   "ed0120601BBDAF858E77B91494885D0A7618A5E21D24D7E4A672AA4C5C0869D2DDE26F@wonderland"
   "26cec43d4fcfcf3341cfd0c9ef2ceda73a64e7c8dd470eb5268bf33be7a80a51"
   {
     "approvals": [
       "ed01201F89368A4F322263C6F1AEF156759A83FB1AD7D93BAA66BFDFA973ACBADA462F@wonderland"
     ],
     "expires_at_ms": 1731520010341,
     "instructions": [
       {
         "Custom": {
           "payload": {
             "Approve": {
               "account": "ed01201F89368A4F322263C6F1AEF156759A83FB1AD7D93BAA66BFDFA973ACBADA462F@wonderland",
               "instructions_hash": "1303A3F8222D9D5D687B8C787BDF6A90A7F774E54A8A37E52FB1681F69E05BA9"
             }
           }
         }
       }
     ],
     "proposed_at_ms": 1731516410341
   }
   "ed0120D94ED925A4049D78A9F1E55FBF0783A8FE21F2F65CCFE714BBE867A18CC630F8@wonderland"
   "6851493706f2010c6054d7ddf524efcc75a49a5b05bc3e7fdd6a2aea38aa982b"
   {
     "approvals": [
       "ed0120601BBDAF858E77B91494885D0A7618A5E21D24D7E4A672AA4C5C0869D2DDE26F@wonderland"
     ],
     "expires_at_ms": 1731520010341,
     "instructions": [
       {
         "Custom": {
           "payload": {
             "Approve": {
               "account": "ed0120601BBDAF858E77B91494885D0A7618A5E21D24D7E4A672AA4C5C0869D2DDE26F@wonderland",
               "instructions_hash": "26CEC43D4FCFCF3341CFD0C9EF2CEDA73A64E7C8DD470EB5268BF33BE7A80A51"
             }
           }
         }
       }
     ],
     "proposed_at_ms": 1731516410341
   }
   

2. Once a direct multisig account has passed approval, the whole status no longer appears to the child signatories

3. TTL is bound to each account, which is a blocker to consistency as the entire multisig transaction hierarchy

4. On expiration, only the approving node that found the proposal expired is deleted. On execution, only nodes on the path from the last approval to the root proposal are deleted. The remaining nodes require other approvals to be completely deleted

5. Execution of multisig instructions is panic-prone when metadata is modified. Related to (multisig) potential inconsistency between the role and the account metadata #5229

• Hopefully completes Ergonomic MST #4930

Solution

1. feat(multisig): pretty list of pending proposals

   After

   {
     "6851493706F2010C6054D7DDF524EFCC75A49A5B05BC3E7FDD6A2AEA38AA982B": {
       "instructions": [
         {
           "SetKeyValue": {
             "Account": {
               "object": "ed01201F89368A4F322263C6F1AEF156759A83FB1AD7D93BAA66BFDFA973ACBADA462F@wonderland",
               "key": "success_marker",
               "value": "congratulations"
             }
           }
         }
       ],
       "proposed_at": "2024-11-13T06:50:22Z",
       "expires_in": "59m 59s",
       "approval_path": [
         "1 -> [0/1] ed0120D94ED925A4049D78A9F1E55FBF0783A8FE21F2F65CCFE714BBE867A18CC630F8@wonderland",
         "1 -> [0/1] ed0120601BBDAF858E77B91494885D0A7618A5E21D24D7E4A672AA4C5C0869D2DDE26F@wonderland",
         "1 -> [1/2] ed01201F89368A4F322263C6F1AEF156759A83FB1AD7D93BAA66BFDFA973ACBADA462F@wonderland"
       ]
     }
   }
   

2. fix(multisig): keep proposals in list while root is pending

3. feat(multisig)!: override TTL per transaction

4. Delete all relevant entries on expiration and execution:

   • fix(multisig): prune expired path on approve
   • fix(multisig): keep proposals in list while root is pending

5. fix(multisig): question existence and format of metadata

Migration Guide

• (api-changes) optional MultisigPropose.transaction_ttl_ms to override the account default
• (api-changes) MultisigSpec MultisigProposalValue metadata values

---

Review notes

Notice the changes to the tests:

• multisig::multisig_recursion_* integration tests
• scripts/tests/multisig.recursion.sh, especially what multisig list output informs

Checklist

• I've read CONTRIBUTING.md.
• I've written tests for the code changes.
• All review comments have been resolved.
• All CI checks pass.

[DCNick3]

Only one minor comment

[s8sato]

Currently this is in iroha_cli as a sample client implementation, but if considered as a common structure to clients, could be moved to iroha. And if considered as a raw query result, could be moved to iroha_torii or somewhere more internal, probably with no humantime and system-dependent time