Fix eth_getStorageAt and uint256 definitions

[JacekGlen]

Motivation

As per the current spec, the tests for the eth_getStorageAt do not match the definition. Specifically the test \tests\eth_getStorage\get-storage.io fails with the following request:

{
  "jsonrpc":"2.0",
  "id":1,
  "method":"eth_getStorageAt",
  "params":
  [
    "0xaa00000000000000000000000000000000000000",
    "0x0100000000000000000000000000000000000000000000000000000000000000",
    "latest"
  ]
}

The second parameter is the 'Storage slot' parameter defined as $ref: '#/components/schemas/uint256'. This has the following issues:

1. The uint256 does not accept the leading 0s. The validation passes if the parameter is changed to "0x100000000000000000000000000000000000000000000000000000000000000".

2. The definition of $ref: '#/components/schemas/uint256' is not valid as it only allows 16 bytes:

uint256:
  title: hex encoded 256 bit unsigned integer
  type: string
  pattern: ^0x([1-9a-f]+[0-9a-f]{0,31})|0$

Summary

This PR fixes eth_getStorageAt definition by setting it to more specific data types. The 'Storage slot' parameter has been changed to $ref: '#/components/schemas/bytesMax32'. This allows any of the values to be valid:

0x0100000000000000000000000000000000000000000000000000000000000000
0x100000000000000000000000000000000000000000000000000000000000000

The result value has been updated to always expect 32 bytes.

Additionally the definition of $ref: '#/components/schemas/uint256' has been extended to 32 bytes.

Notes

For the 'Storage slot' parameter I used bytesMax32 rather than bytes32 or hash32 for two reasons:

• ease of use for fixed-sized variables, i.e. use 0x1 rather than 0x0000000000000000000000000000000000000000000000000000000000000001
• backwards compatibility

[fjl]

Fixed in #605