Engine API: define Open RPC schema

[mkalinin]

Defines initial OpenRPC schema for Engine API. Draft PR opened up for review, once agreed in general getPayloadBodies requests should be added before merging.

Folder structure

schemas/ and methods/ are both put into src/engine/openrpc/ to avoid messing Open RPC schema files with method specification files which are main artifacts of src/engine part of this repo.

Schema files follows functional breakdown as it should be easier to read and maintain it this way. I tried to play with functional & version breakdown, like payload_v1.yaml, payload_v2.yaml, and didn't find version breakdown useful at all.

Spellchecker

This PR makes spellchecker case insensitive for .yaml files, this is done merely to avoid adding words respecting the case to the exception list. If case sensitivity for yamls is important by any mean then we'll have to add those words explicitly.

External docs

Tried to play out with externalDocs property. Unfortunately, it isn't rendered by OpenRPC playground at all. But I decided to leave this property as it might be useful. Currently it contains full URL to specification of each method.

Misc

TBH, I am not satisfied with deduplication framework of JSON schema. I was expecting to define ExecutionPayloadV2 by giving a command to use ExecutionPayloadV1 property set with withdrawals field addition. Apparently, it's not allowed. Though, I am not an expert and it might be possible to do, lmk.

ToDo

• Add definition of payload bodies requests
• Add tests

[lightclient]

I am not satisfied with deduplication framework of JSON schema

Were you able to try using allOf? This is how signed transactions are able to reuse the unsigned format. See here.

--

From a high level view, this PR generally seems good. No way to really know how correct the schema is without some tests, but not sure if you want to add that here. I worked on a tool rpctestgen which makes it pretty easy to update tests for the eth RPC. I think something similar would be useful for the engine api. Although the regeneration is less of an issue because breaking should require a version bump of the method or object.

Would be great have sample messages to sanity check the spec, regardless of how they are acquired though. Even just listening in over some EL<>CL interactions and snagging a couple unique method calls would probably suffice for now.

[lightclient]

Noticed a couple things while reviewing manually