Add new FuelGasPriceProvider

[MitchTurner]

Part of: #1624

Introduce a new type to replace StaticGasPrice that will actually calculate new gas prices based on historical data. For now we're just faking all the input sources to show that the algorithm can work.

This work is largely exploratory since we don't know exactly what the algorithm will land on. This means that the algorithm might need to be moved to a versioned subtype before this work is done. But hopefully we can either land on a good MVP algorithm or unearth more specifications for our algorithm through this work 🤞

The current design separates the algorithm from the FuelBlockProvider. This helps identify what behavior is independent of the specifc algorithm we end up choosing and helps us determine the minimum set of variables the algorithm requires. It's possible that we will need more or fewer params. Currently the algorithm looks like this:

pub trait GasPriceAlgorithm {
    fn calculate_gas_price(
        &self,
        previous_gas_price: u64,
        total_production_reward: u64,
        total_da_recording_cost: u64,
        block_fullness: BlockFullness,
    ) -> u64;

    fn maximum_next_gas_price(&self, previous_gas_price: u64) -> u64;
}

Taking the total of both reward and cost could instead be a profitablility ratio, but that robs the control loop of information about the magnitude of the difference in the units of gas_price. i.e. being 20% away from the target profitability is much different if it's accrued over 100 blocks or 100,000 blocks. It's still TBD.

The actual impllementation of the FuelGasPriceAlgo for now is going to take inspiration from a PID control loop, but ideally as simple as possible and as deterministic as possible (we don't want to use floats in places like BlockFullness).

Architecture Diagram (WIP, I'll try to update as it changes). CLICK IF NOT SHOWING UP PROPERLY IN DARK MODE:

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog
• New behavior is reflected in tests
• The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

• I have reviewed the code myself
• I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

• Rust SDK
• Sway compiler
• Platform documentation (for out-of-organization contributors, the person merging the PR will do this)
• Someone else?

[MitchTurner]

We might want to take into account the average number of txs per block. Or we could get a similar result with an "I" value (PID).

[MitchTurner]

We need to take into account the fact that DA recording has some lag to it. Possibly 12-24 blocks? How does that effect the gas_price calculation? The current design doesn't take that into account.

[MitchTurner]

This is kinda a smell. I'm not sure if this should be in the provider or the algo. I'm getting a feeling like the provider and the algo abstractions could be merged some, especially when we start looking at the estimation trait impl.