graphql: add field yParity

[jsvisa]

No description provided.

[lightclient]

LGTM

[s1na]

@shemnon Please take a look. This is consistent with the JSON-RPC. We have to return yParity for type-1 and type2 transactions instead of v. (More context: paradigmxyz/reth#3798)

[shemnon]

Looks reasonable.

Why Long over BigInt? JSON-RPC encodes yParity as a uint not a uint64, and Long limits to 64. It's not an input parameter so queries passing in numbers shouldn't matter.

[s1na]

Given that r, s and v are also BigInt I tend to agree 👍

[s1na]

Come to think of it, v should become nullable. It will be null for type-1 and type-2 txes.

[shemnon]

we also need to merge #468 which impacts the graphql apis.

[fjl]

The value of yParity is always 0 or 1. So it makes no sense for it to be a BigInt. There are only two possible values in responses: 0x0 or 0x1. Not sure how this could be encoded into the schema.

[shemnon]

The argument for BigInt is for consistent handling with mappings from the JSON-RPC api, because it is just uint there which maps to BigInt for r and s. Long is to much as well. What is really needed is a type that means "hex integer output" which is what BigInt fulfills.