[CX-Marketplace] - Add Support for Multiple Version Paths From `AuctionResults`

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

HotShot needs to be able to accept multiple fees for a block to allow for multiple builders to submit bundles with requisite fees as a result of the Solver’s allocation result. Because of this, we’ll need to extend the flow of the Transactions task to support in-loop web requests depending on which version of the code we’re running.

The existing flow in the Transactions task is as follows:

HotShotEvent::ViewChange() => {
...
    let block = {
        if self
            .decided_upgrade_certificate
            .as_ref()
            .is_some_and(|cert| cert.upgrading_in(block_view))
        {
            None
        } else {
            self.wait_for_block().await
        }
    };

    if let Some(BuilderResponses {
        block_data,
        blocks_initial_info,
        block_header,
    }) = block
    {
        // Broadcast the block
        ...
    } else {
        // If we couldn't get a block, send an empty block
        warn!(
            "Failed to get a block for view {:?}, proposing empty block",
            view
        );
            // Construct a null block
            ...
    };
...
}

This will be one of the first blocks of versioned code that we interact with. In this, we’ll adjust the wait logic to instead query the solver service via the Sequencer by leveraging the versioning check (defined below) to execute the proper code path depending on what version of hotshot we’re interacting with.

HotShotEvent::ViewChange() => {
...
    let blocks = if self.version >= Marketplace {
            let results = self.auction_results_client.fetch_auction_result(
                block_view
            ).await?;
            let bundles = self.query_all_builders(urls).await?;

            // Build the block
            Some(bundles.map(|b|b.url()))
    } else {
        Some(vec1![self.wait_for_block().await])
    };
...
}

An easy way to construct blocks is to take the bundles from the Builders as a list of transactions instead of a list of bytes and hotshot could compress this down into bytes and construct the Arc<[u8]> type from there.

VID Precompute won’t be already present, we’ll be calculating this ourselves right before we submit the BlockRecv event.

Need to do that async spawn operation that we do in other spots to ensure that we don’t block out when doing this.
A HotShot function function exists for this already.

For the remaining fields, we can construct the BlockRecv field from the new proposed payload type. So all of the requisite information should be present.

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

No response

Are there any other details to include?

No response

What are the acceptance criteria to close this issue?

The block event is completely implemented with all version support and testing.

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

No response

EspressoSystems / HotShot