Implements Pre-Confirmations Decay Handling for Smart Contracts

[ckartik]

New Mechanism: Decay Funds Movement (Part 2 of 3)

This PR introduces the 'Decayed Pre-confirmations Reward Logic' Into the smart-contracts workflow
(See Part 1 in mev-commit for backgound)

• Commitment from the provider will now store the following details:
• The Decay Timeline Parameters
• The Block in which the decayed commitment was stored on mev-commit-chain

Funds movement details:

• The slashing amount will now correspond to the decayed amount of the bid. This is to avoid incentives for the bidder to manipulate the decay timeline and ensure the protocol handles the decayed bid uniformly across modes of fund movement.
• The reward will now be decayed based on the Oracle driven Decay Percentage, provided in the processBuilderCommitmentForBlockNumber trigger
• The fee to the protocol will be on the decayed bid amount, not the genesis bid amount (amount specified in bid field)

Rationale for keeping decay computation in the Oracle

• The long term vision of the mev-commit-chain may involve us moving away from using block timestamps to detect fulfilment of commitments. As such, externalizing the recognition of when a commitment is "recognized allows us to build in extensibility for the future
• Due to timestamps currently being encoded in Seconds, the granularity of on-chain computation of decay would be lacking, unless we introduce ms timestamps.
• Given both above considerations, the decision was made to keep decay computation in the Oracle.

Please refer to the diagram below for a visual representation of the process:

Additional Changes Made

• Revamping of portions of the test suite for simplicity of open-source contribution.

[shaspitz]

Nice work!