graphql: specify Long input and output formats

[s1na]

TL;DR After this PR every number field will be hex-formatted. Numeric inputs are flexible and can be provided as number or string.

The spec is vague in defining which inputs are accepted for Long and how outputs are formatted. I suggest that Long behave similar to BigInts in this sense. I.e. be flexible when taking input, but output hex-encoded values. My reasoning is that:

• JSON-RPC API returns all the long values as hex.
• Even though BigInt is a thing in JS-land, parsing a big uint64 literal in JS will still be inaccurate. Case in point this happens also in the GraphiQL UI which both Besu and Geth use this issue exists. There's a proposal which will help with this however it is not accepted for being included into the EcmaScript spec.
• That said we can improve UX by accepting number literals as well as strings for inputs.

Every field with type Int has been changed to be a Long for consistency.

Hive tests: ethereum/hive#746

[shemnon]

Looks reasonable. Any idea of the scope of the downstream impact? i.e. do you know of anyone we will break?

[shemnon]

I also think that if we are going to hex for the longs, we should consider all-hex, or at least align with what the json-rpc results send on a per-field basis.

[s1na]

Any idea of the scope of the downstream impact? i.e. do you know of anyone we will break?
Unfortunately not.

I also think that if we are going to hex for the longs, we should consider all-hex, or at least align with what the json-rpc results send on a per-field basis.

Fair enough. json-rpc result sends back hex for every number AFAIK. At least checked all cases where graphql currently returns decimal and they are all returned as hex in json-rpc.

Currently their type is Int in the schema. I will change them to Long since Int is a graphql defined type and I'd rather we don't override its behavior.

[s1na]

Updated the hive tests as well, PTAL.