Add support for querying contracts by ID

[roman-khimov]

Summary or problem description
The initial problem that led to this issue was that I wanted to make native contracts be discoverable via RPC. At the moment clients have to have GAS/NEO/Policy hashes to make any queries/transactions using them. Usually of course they don't change and these values can be hardcoded into the client. Still, if we're to make some changes (and to this date there is no preview version of Neo 3 that didn't change them) or if we're to deploy some private network with additional contract there is a question of client updates. The actual data is known to the RPC server, so if it could somehow convey this knowledge to the client that would be solved.

So I thought about some new API like listnativecontracts, but then remembered that we actually have now way more stable contract identifies, their ID numbers. And there is a simple scheme of numbering, going down from zero for native contracts and going up for regular ones.

Do you have any solution you want to propose?
If we're to enable getcontractstate RPC call to accept IDs (along with hashes) then we can make all our contracts easily enumerable and discoverable by clients. So the client may no longer store NEO hash, it can query contract -1 and get it. Same thing for other contracts, native or regular ones.

Where in the software does this update applies to?

• Plugins

[shargon]

@roman-khimov please take a look to #340 I think that it easier for users if the can query contracts by name, instead of by id

[roman-khimov]

It's a nice extension too, it solves the original problem for sure (and in a bit more friendly fashion as "NEO" is better than "-1"). But at the same time ability to enumerate both native and regular contracts has a value of its own, so maybe we can add support for three types of arguments here --- hash, name and ID?

[shargon]

I think that Id it's something more "internal" but it's ok for me, the PR was updated.

[erikzhang]

I think that Id it's something more "internal"

I think so too.

[roman-khimov]

We expose this ID in answers to getcontractstate queries:

$ curl -d '{ "jsonrpc": "2.0", "id": 5, "method": "getcontractstate", "params": ["ce06595079cd69583126dbfd1d2e25cca74cffe9"] }' seed2t.neo.org:20332 | json_pp
{
   "result" : {
      "hash" : "0xce06595079cd69583126dbfd1d2e25cca74cffe9",
      "id" : -3,
...

So it's available to the general public for use or misuse anyway.