Participation format in BeaconState result is out of spec

[marioevz]

Describe the bug
During testing on hive with nimbus beacon client, hive uses https://github.com/protolambda/zrnt to parse the REST API results, and is currently resulting in error during a query to eth/v2/debug/beacon/states/head.

The reason is that nimbus currently returns two values which are out of spec on previous_epoch_participation and current_epoch_participation, which are specified as List[ParticipationFlags, VALIDATOR_REGISTRY_LIMIT] (effectively a list of uint8), both specified here https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md#beaconstate

Current result from nimbus is:

"previous_epoch_participation": "0x0707070707070707...

instead of the expected

"previous_epoch_participation": ["7","7","7", ...

Hive simulator is aborting early due to this.

To Reproduce
On nimbus running altair fork or later:
curl http://127.0.0.1:4000/eth/v2/debug/beacon/states/head

[arnetheduck]

So - ParticpationFlags is an alias for uint8 per the consensus spec.

The other place where we have a List[uint8] is extra_data from bellatrix - there, the expected serialization is "0x....": https://github.com/ethereum/beacon-APIs/blob/44dcaee00f3366f17f8b5c7651d6cdc70826ad3a/types/primitive.yaml#L89=

The beacon API spec leaves BeaconState unspecified as far as canoncial JSON serialization goes, ergo this would a an open question to decide in the that spec before picking one format over the other - presumably, life would be easier if all List[byte] were serialized the same: ethereum/beacon-APIs#219

[arnetheduck]

Turns out there's a spec for this that I missed: ethereum/beacon-APIs#219 (comment)