Check both node and alphabet signature in netmap contract

[fyrchik]

Wait until nspcc-dev/neo-go#2150 is resolved.

[alexvanin]

I found interesting thing when I was testing nspcc-dev/neo-go#2150 with reverted #155

Storage node prepares AddPeer tx with 4 witnesses. It passes test invocation and node sends notary request.
Alphabet nodes do not resign this tx. Instead they extend NodeInfo with LOCODE attributes, hence create new AddPeer tx with 3 witnesses (no storage node witness anymore). And test invoke now fails.

We must consider this, simple revert is not enough.

[alexvanin]

AddPeer is indeed the main issue there. It must contain runtime.CheckWitness(nodeInfoKey) otherwise it will be possible for malicious user to create notary tx with AddPeer invocation that includes someone else's public key.

However Alphabet nodes create new AddPeer invocation transaction due to changes in Storage node attributes (e.g. LOCODE parse). Therefore Alphabet nodes cannot provide original witness and runtime.CheckWitness(nodeInfoKey) will always fail.

There are several options how we can handle it:

1. Split AddPeer into two methods for notary enabled environment

First method will contain runtime.CheckWitness(nodeInfoKey) check. Alphabet nodes will listen notary notification for this method. But to approve new peer, Alphabet nodes will invoke second method that contain runtime.CheckWitness(alphabetMulitisig).

Pros: no additional changes in Storage node.
Cons: additional method in contracts.

2. Storage node should attach only it's own witness in AddPeer invocation.

Alphabet nodes must check if AddPeer invocation omits Alphabet mulitisignature witness and contains only it's own witness.

Pros: no changes in contract.
Cons: inconvenient scheme of notary invocations in Storage node.

3. Do not modify Storage node attributes

Even if we can solve LOCODE attribute issue by attaching database in Storage node releases, it won't work with dynamic attribute changes for subnetworks.