Add the transaction handling for `EscrowCreate.Bytecode`/`Data` and
`EscrowFinish.Gas`, gated on `featureSmartEscrow`. The field and result-code
plumbing landed in #8157.
EscrowCreate:
* `Bytecode` joins `FinishAfter` and `Condition` as a way to say how an escrow
completes, but always needs a `CancelAfter`: nothing else can free the funds
if the contract never accepts.
* `Data` requires `Bytecode` and is capped at `kMaxWasmDataLength`.
* Bytecode is capped at the voted `BytecodeSizeLimit`, and refused outright
when fee voting has zeroed `GasLimit` or `BytecodeSizeLimit`.
* The fee is ten base fees plus five drops per byte.
* The owner reserve is one increment per 500 bytes beyond the first 500, on
top of the increment every escrow costs. EscrowCancel and EscrowFinish
refund what was taken.
EscrowFinish:
* `Gas` is bounded by the voted `GasLimit` and costs `GasPrice` micro-drops
each.
* `Gas` and the escrow's `Bytecode` must both be present or both absent
(tefBYTECODE_NOT_INCLUDED / tefNO_BYTECODE).
* The destination and deposit-preauth checks move ahead of the condition
check, so a contract never runs against a destination that cannot receive.
The WASM engine is not in this build, so nothing runs the bytecode: creating,
funding and cancelling a Smart Escrow works, and finishing one reports
tecFAILED_PROCESSING at the TODO where the contract would run. The gas and
return-code metadata, tecBYTECODE_REJECTED, and the `Data` a rejected contract
leaves behind all arrive with the engine. Reachable only under
`featureSmartEscrow`, which is `Supported::No`.
The stream assertions covered `gas_limit` and `bytecode_size_limit` but not
`gas_price`, which is published from the same place and voted by the same
helper. Assert it too, on both the enabled and the disabled path.
Reported by Copilot on #8214.
`doVoting` built the three gas votes unconditionally. Before the amendment,
the ledger reports zero for all three while the config targets are non-zero by
default, and the loop that collects validator votes is itself gated on the
amendment — so the vote map held only our own target and every one of the
three reported a change.
The result was a `SetFee` pseudo-transaction on every flag ledger, from every
node running this build, for as long as the amendment stayed disabled. The
transaction carried no gas fields, since that part was gated correctly, so it
proposed no change at all.
Gate the three flags on the amendment, matching `doValidation`, which already
had its gas votes inside the same check.
Reported by xrplf-ai-reviewer on #8214.
`FeeSetup::toFees()` returned the three-argument `Fees`, leaving `gasLimit`,
`bytecodeSizeLimit` and `gasPrice` at zero. `startGenesisLedger` passes that
straight into the genesis `Ledger`, which is where those three are written to
the `FeeSettings` entry — so a network started fresh with `featureSmartEscrow`
in its initial amendment set got a gas limit of zero, i.e. Smart Escrow
switched off no matter what the operator configured.
Carrying them through `toFees()` alone is not enough. Every `Ledger` built
from stored data is seeded with the same `Fees`, and `Ledger::setup()` only
overwrites the fields the `FeeSettings` entry actually carries. A ledger from
before the amendment carries none, so the seed would survive and the node
would read its own configuration back as though the network had agreed to it —
and then never vote for the values it wants, because `doValidation` only votes
when the current setting differs from the target.
So the genesis constructor now clears the three whenever it does not write
them. A ledger reports what its `FeeSettings` entry holds, and nothing more.
Reported by depthfirst-app and Copilot on #8214.
Add `GasLimit`, `BytecodeSizeLimit`, and `GasPrice` to the network's votable
fee settings, gated on `featureSmartEscrow`.
The `.macro` and autogen plumbing for these fields landed in #8157; this adds
the behavior behind them: config parsing, fee voting, the `SetFee` pseudo-
transaction, `FeeSettings` genesis and load, and the RPC surfaces that report
fee settings.
`detail::VotableValue` in FeeVoteImpl.cpp becomes a template, since the three
new settings are `std::uint32_t` rather than `XRPAmount`.
`ServiceRegistry::getFees()` exposes the configured settings to code that has
no `ReadView`. It has no production caller yet; the Smart Escrow transactors
call it from `preflight`.
