Removed Redundant JSON Structures

[ethDreamer]

When I originally wrote a lot of this engine_api code, I thought it would be best to create separate JSON structures for objects defined in the engine api. The engine_api objects are versioned (e.g. ExecutionPayloadV1) but often correspond to spec objects (e.g. ExecutionPayload) so I thought having separate versioned JSON structures would be cleaner for future API changes.

However, the proposed changes for Capella have the engine_api object versions corresponding directly to the fork variants of the spec objects. So for now it is significantly cleaner and reduces a lot of duplicated code to just remove the separate Json* objects and use the underlying spec objects directly.

The only Json* object I didn't get rid of was:

#[derive(Debug, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct JsonForkchoiceUpdatedResponse {
    pub payload_status: PayloadStatusV1,
    pub payload_id: Option<TransparentJsonPayloadId>,
}

because the PayloadId requires a custom serializer but concisely applying a custom serializer to T in an Option<T> has been an open issue in serde for 5 years

• Using de/serialize_with inside of an Option, Map, Vec serde-rs/serde#723

and just having a separate object solves it nicely.

[realbigsean]

Definitely seems like we can remove the Json types for any types that are only in the execution API. But the ExecutionPayload and ExecutionPayloadHeader are tricky because they have different JSON serializations in the execution API vs the beacon API (camel case vs snake case and hex vs decimal numbers). I think it's easiest to have two sets of types for those. Or maybe we could add a superduperstruct that generates two superstructs with alternate sets of serde_derive attributes.

[ethDreamer]

But the ExecutionPayload and ExecutionPayloadHeader are tricky because they have different JSON serializations in the execution API vs the beacon API

ah I didn't realize this - that puts a damper on this whole thing then :/
For now I think the best course of action is to just leave in the Json* structures and use a macro to implement the conversions between them.

maybe we could add a superduperstruct that generates two superstructs with alternate sets of serde_derive attributes

any thoughts on this @michaelsproul?

[ethDreamer]

On second thought, there are additional cases like WithdrawalV where objects are encoded differently in the engine_api than they are represented in the beacon chain. This touches on that whole big vs. little endian complication.. this lends itself to having separate structures that are easy to convert between.. it's looking like my assumption when I initially designed this was correct..