Adding a shielding fee for normal shielding txs.

[batconjurer]

Describe your changes

Closes #4716

Checklist before merging

• If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
  • This will require 2 reviewers to approve the changes
• If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
  • Relevant PR if applies:
• If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
  • Relevant PR if applies:

[grarco]

Quick idea I haven't reasoned too deeply about (especially in terms of safety): would it be possible to avoid this new section type and encode all the necessary data directly inside the Transfer data section? Maybe we could just add two entires: the fee payer as a source and the PGF account as the target. The multitransfer function will just update the balances accordingly. The masp vp should have all the necessary data to check if the PGF account has been credited the fees when the vector of inputs of the transparent bundle is non-empty. It should also be able to verify that the amount credited to the PGF account is in a supported token and matches the expected amount for that token

[batconjurer]

The difficult part would be knowing which masp tx was paid for it multiple shields are in a batch. We need a commitment.

[sug0]

@grarco I'm doing something similar in the FMD PR I have open

namada/crates/token/src/lib.rs

Lines 185 to 186 in e8b2722

	/// Pointers to MASP data within a transfer tx
	pub shielded_data: Option<MaspTxData>,

namada/crates/core/src/masp.rs

Lines 112 to 122 in e8b2722

	pub struct MaspTxData {
	/// Id of the MASP transaction.
	///
	/// This is used to look-up a MASP transaction section.
	pub masp_tx_id: MaspTxId,
	/// Section hash of the FMD flag ciphertext.
	///
	/// This is used to look-up a transaction data section
	/// containing an FMD flag ciphertext.
	pub flag_ciphertext_sechash: Hash,
	}

the fmd section is stored in Section::ExtraData, thus is implicitly signed when we sign the tx_transfer data

this still breaks the hw wallet tho, I think, because the parsing of the masp tx data section is now different (the field is larger). it def did in the fmd pr

[sug0]

overall this is correct, in terms of impl alone. we should check in with @cwgoes that this meets the desired design principles. also, should pitch in some opinion from @murisi about the hw wallet changes required

[brentstone]

Let's get some new reviews here