Some commands don't accept arguments, but users try giving them and don't
notice a mistake. It's a bit more user-friendly to tell the user that there is
something wrong with the way he tries to use the command.
It has a stub for SIGHUP, but doesn't have anything for USR1 and USR2:
Error: cli\server\server.go:520:31: undefined: syscall.SIGUSR1
Error: cli\server\server.go:521:31: undefined: syscall.SIGUSR2
Error: cli\server\server.go:565:17: undefined: syscall.SIGUSR1
Error: cli\server\server.go:608:17: undefined: syscall.SIGUSR2
Which allows to enable/disable the service, change nodes, keys and other
settings. Unfortunately, atomic.Value doesn't allow Store(nil), so we have to
store a pointer there that can point to nil interface.
Turns out, our getnextvalidators implementation already works the way
getcandidates is supposed to work, but original getnextvalidators works a bit
differently. It only returns validators, it doesn't return Active flag (all
of them are active) and it represents votes as a number. So for the maximum
compatibility:
* drop non-validator keys from getnextvalidators server-side
* drop Active flag client-side (sorry, it doesn't exist)
* allow unmarshalling old answers along with the new one
This technically breaks `query candidates` CLI command, but it'll be fixed
when getcandidates are to be introduced.
https://github.com/nspcc-dev/neo-go/pull/2435 breaks compatibility
between newer RPC clients and older RPC servers with the following
error:
```
failed to get network magic: json: cannot unmarshal string into Go struct field Protocol.protocol.initialgasdistribution of type int64
```
This behaviour is expected, but we can't allow this radical change.
Thus, the following solution is implemented:
1. RPC server responds with proper non-stringified
InitialGasDistribution value. The value represents an integral
of fixed8 multiplied by the decimals.
2. RPC client is able to distinguish older and newer responses. For
older one the stringified value without decimals part is
expected. For newer responses the int64 value with decimal part
is expected.
The cludge will be present in the code for a while until nodes of
version <=0.98.3 become completely absolete.
Old help message is misleading a bit:
```
OPTIONS:
--verbose, -v Output full tx info and execution logs
--rpc-endpoint value, -r value RPC node address
--timeout value, -s value Timeout for the operation (10 seconds by default) (default: 0s)
```
The new one:
```
OPTIONS:
--verbose, -v Output full tx info and execution logs
--rpc-endpoint value, -r value RPC node address
--timeout value, -s value Timeout for the operation (default: 10s)
```
