Only charge custom fees given explicit willingness-to-pay

[tinker-michaelj]

The network will only charge Alice a custom fee if Alice has signed the active transaction.

But Alice might sign a transaction, expecting the custom fee to be 1 ℏ---or even 0 ℏ---only to discover later that the actual fee was 1M ℏ. This unfortunate scenario would almost always be the result of malicious behavior; and since Alice only interacts with trusted tokens and smart contracts, they are not worried.

Nonetheless, Alice is not the only user on the network.

We suggest a safeguard against this kind of exploit. Define the following protobuf message, which sets the maximum willingness of a given account to pay a custom fee in a given denomination:

message MaxCustomFee {
    // The account id of the consenting payer; if not set, the top-level transaction payer
    AccountID payer_id = 1;

    // The denomination of the fee being consented to; if not set, ℏ
    TokenID demoninating_token_id = 2;

    // The maximum amount the payer is will to pay in the above denomination
    int64 amount = 3;
}

Then add a new field to the TransactionBody message:

    repeated MaxCustomFee max_custom_fees = 52;

and fail any transaction that attempts to charge a custom fee for which max_custom_fees list does not assert willingness-to-pay.

[Nana-EC]

Agreed on this approach.
Being able to specify at a transaction level the max value extracted from an entities balance separate from the transaction fees would be good.
For scenario that don't support HAPI transaction signatures such as smart contract executions we could rely on secure practices such as value allowance approvals from the owner to the fee receiving entity