It's not needed any more with Go 1.13 as we have wrapping/unwrapping in base
packages. All errors.Wrap calls are replaced with fmt.Errorf, some strings are
improved along the way.
MarshalJSON should be defined on structure (not pointer), as we use
structures to marshal parameters (e.g. in NotificationEvent and
Invoke of RPC result package) and never use pointers for that purpose.
Also added marshalling of nil array into `[]` instead of `null` to
follow C# implementation.
Neo 3 can emit Null in its transfer notifications in `from` or `to` fields
when minting/burning tokens (unlike Neo 2 that emitted util.Uint256{} for this
case), then it gets converted to Parameter as AnyType and we have to JSONize
it somehow for proper RPC functioning.
We actually have to do that in order to answer getapplicationlog requests for
transactions that leave some interop items on the stack. It follows the same
logic our binary serializer/deserializes does leaving the type and stripping
the value (whatever that is).
There's a bug after #785: smartcontract.Parameter of type hash160 should
be marshalled in LE (as default marshaller for uint160 does) instead of
BE, so fixed.
Fixes#809.
Basically, there are three alternative approaches to fixing it:
* allowing both []byte and string for ByteArrayType value
minimal invasion into existing code, but ugly as hell and will probably
backfire at some point
* storing string values in ByteArrayType
incurs quite a number of type conversions (and associated data copying),
though note that these values are not changed usually, so dynamic
properties of []byte are almost irrelevant here
* storing only []byte values in ByteArrayType
makes it impossible to use them as map keys which can be solved in several
ways:
- via an interface (Marshalable)
which is good, but makes testing and comparing values in general harder,
because of keys mismatch
- using serialized Parameter as a key (in a string)
which will need some additional marshaling/unmarshaling
- converting MapType from map to a slice of key-value pairs
not a bad idea as we don't use this map as a map really, the type
itself is all about input/output for real VM types and this approach is
also a bit closer to JSON representation of the Map
