Merkle (Patricia) proof interface and implementation about exonum-client HOT 2 OPEN

@boguslavsky @defuz @gisochre Are you OK with this interface? Maybe, ListView or MapView need to have other methods? As for JSON for constructors, I see it slightly more verbose than it is currently, in order to be parseable within generic Exonum type spec:

ListView (3 items, proofs for 1st and 3rd):

{
  "root": {
    "@type": "branch",
    "left": {
      "@type": "branch",
      "left": {
        "val": ...
      },
      "right": {
        "stub": "abcdef..."
      }
    },
    "right": {
      "@type": "sprout",
      "child": {
        "val": ...
      }
    }
  },
  "length": 3
}

MapView (proof for key 01101...; the bits field is embedded into variants):

{
  "@type": "branch",
  "bits": "",
  "left": {
    "@type": "branch",
    "bits": "0",
    "left": {
      "stub": {
        "bits": "01",
        "hash": "..."
      }
    },
    "right": {
      "val": {
        "bits": "1101...",
        "item": ...
      }
    }
  },
  "right": {
    "stub": {
      "bits": "1",
      "hash": "..."
    }
  }
}

This assumes that oneOf can be encoded either as {<tag>: <value>} or {"@type": <tag>, ...<value>}.

As for implementation, it could be first implemented with custom JSON parsing logic, and then integrated into the Exonum type system.

from exonum-client.

I've implemented a PoC for type defs, which includes possibility of tree implementation, among other things. Very rough, but you probably get the general idea.

from exonum-client.