fix(consensus)!: read-only resource + other fixes

[sdbondi]

Description

• Resources are locked as read-only in consensus
• Greatly reduce the size of the fee breakdown in transaction receipt
• Fix mempool incorrect involvement detection
• Fix consensus crash if versioned substate requirement is already DOWN
• Fix off-by-one error when sending state transitions in state sync

Motivation and Context

Resources are highly contended and therefore are read-only after creation. Any transaction that mutates the resource will fail however the template API has not changed in this PR to reflect that.

Any mints/burns after the initial mint will succeed only in the local-only case, multi-committee mints/burns will fail.

Ideas for improvements:

1. Easy way: Allow user to specify read/write for resources (or perhaps substates in general). Cons: poorer UX
2. Complex: initially locked as read-only until AllPrepared phase. Transaction is executed and if the transaction results in a write for the resource. The write lock is queued and no further progress can be made on the transaction until all preceding write/read locks are released. Once this occurs the transaction is re-executed and LocalAccept proposed with as a write.
3. To improve concurrency, a resource issuer may lock their resource for a period guaranteeing that no minting/burning or access rule changes can occur until that period expires.
4. Automatically and implicitly read lock a resource for a guaranteed period of time (epochs). A user may submit a transaction that updates the resource, but that transaction will not be sequenced until the lock expires.
5. Add a resource mint/burn instruction which will only involve a single shard. This will naturally "park" the transaction until any multishard locks are released and a local-only mint/burn/access rule update is performed.
6. Eventual consistency: Total supply and access rule changes will eventually reflect. All resource operations are logged and eventually applied in an atomic way across shard groups, perhaps with a special signed cross-shard message that will be locally proposed.
7. Apply point (1) and check access rules for the resource. If the signer is not permitted to write the resource at locking/pledging time (before execution), the transaction is aborted. This is more related to security, not concurrency.

How Has This Been Tested?

Manually

What process can a PR reviewer use to test or verify this change?

Submit transactions that concurrently read from the resource address.

Breaking Changes

• None
• Requires data directory to be deleted
• Other - Please specify

[github-actions]

Test Results (CI)

561 tests   - 1   561 ✅  - 1   1h 41m 46s ⏱️ + 9m 23s
 61 suites ±0     0 💤 ±0 
  2 files   ±0     0 ❌ ±0 

Results for commit fd7671a. ± Comparison against base commit 5431162.

This pull request removes 1 test.

tari_dan_engine::test ‑ nft_indexes::new_nft_index

♻️ This comment has been updated with latest results.