[CX-Marketplace] - Define the AuctionResults Trait

[jparr721]

What is this task and why do we need to work on it?

We need to create and implement the AuctionResults trait within HotShot and Sequencer to ensure that the results from the Solver are accessible to HotShot in a way which obscures it’s need to know the details of the data types of the Solver. The trait will be defined roughly as the following:

#[async_trait]
trait AuctionResults<TYPES: NodeType> {
	type AuctionSolverResult;

	async fn fetch_auction_result(
		self, 
		view_number: TYPES::Time
	) -> Result<Vec<AuctionSolverResult>>;
}

IMPORTANT: Sequencer has no state whatsoever about the fetched results. Each request is not a singleton and, as a result, HotShot’s storage mechanism will need to handle holding this information if it’s needed for longer than just the block construction. Due to the volume of the data, it is not suitable for event propagation and, instead, should be stored centrally.

This trait depends on making async calls to the solver over HTTP, collecting the results into whatever the Sequencer defines AuctionResult as, and then sending it down to HotShot. So this work will require a test types type for the auction result, this will likely just need to be the URL values. This trait will exist within the types crate in HotShot, and derive from NodeImplementation (i.e. I::AuctionResults). An approximate test implementation may look something like the following:

struct TestAuctionSolverResult {
	url: URL
}

struct TestAuctionResults {
	solver_results: Vec<TestAuctionSolverResult>,
	
	// Canned type for injecting an error during testing (for vetting failure paths)
	should_throw_error: bool
}

impl AuctionResults<TestTypes> for TestAuctionResultsSomething {
	type AuctionSolverResult = TestAuctionSolverResult;
	
	async fn fetch_auction_result(
		self, 
		view_number: <TestTypes as NodeType>::Time,
	) -> Result<Vec<Self::AuctionSolverResult>> { Ok(self.solver_results) }
}

And this should be all that’s needed to support this within HotShot for testing purposes. Consensus team (@jparr721) has requested to implement this trait within the sequencer repo as well, which is covered in a separate ticket..

What work will need to be done to complete this task?

No response

Are there any other details to include?

Changing the SystemContext might bring about a lot of noise in the changes, but the surface should be manageable in one PR.

What are the acceptance criteria to close this issue?

The trait is defined and implemented in the NodeImplementation module, is able to be added to the SystemContext via the init method, and all tests are passing.

Branch work will be merged to (if not the default branch)

No response