Feature/etcm 533 non membership proof

[bsuieric]

Proofs for non existent values(keys)

In case an address or storage-value does not exist, the proof needs to provide enough data to verify this fact. This means the client needs to follow the path from the root node and deliver until the last matching node. If the last matching node is a branch, the proof value in the node must be an empty one. In case of leaf-type, it must be pointing to a different relative-path in order to proof that the requested path does not exist.

Specification: https://eips.ethereum.org/EIPS/eip-1186
Jira ticket: https://jira.iohk.io/projects/ETCM/issues/ETCM-533

Proposed Solution
following similar implementation with geth client: in case of non existing account, an error should be returned. In case of non existing storage keys, the proof should be returned with default value 0

Manual tests based on other clients are welcomed

[dmitry-worker]

major:
Please add some tests with negative scenarios! (when the proof is not found for example)

minor:
As soon as we have

  case class StorageProof(
      key: StorageProofKey,
      value: BigInt,
      proof: Seq[ByteString]
  )

we can probably replace the resulting tuples in some of the methods with a similar structure, that can be upgraded to a StorageProof when storage key is available. StorageProof can also inherit the Proof trait and represent it without copying, if needed.

[dzajkowski]

@bsuieric looks like it's not formatted

[AnastasiiaL]

Nice addition with tests for MPT and making a proof always return a root node! Now we are following the spec, but with this we part ways with geth, which returns an empty proof instead of Seq(rootNode). Can you check if besu does the same as geth? We need to make a decision here - to follow the spec or other clients implementation.