Add hash of the TX that generated notification
to neofs/netmap event structures. Adapt all
neofs/netmap wrapper calls to new structures.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Prepare all listening structures for notary events:
rename(add prefix/suffix 'notification') all
notification specific handlers/parsers.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
There is a need to work with a set of Neo RPC nodes in order not to depend
on the failure of some nodes while others are active.
Support "multi-client" mode of morph `Client` entity. If instance is not
"multi-client", it works as before. Constructor `New` creates multi-client,
and each method performs iterating over the fixed set of endpoints until
success. Opened client connections are cached (without eviction for now).
Storage (as earlier) and IR (from now) nodes can be configured with multiple
Neo endpoints. As above, `New` creates multi-client instance, so we don't
need initialization changes on app-side.
`Wait` and `GetDesignateHash` methods of `Client` return an error from now
to detect connection errors. `NotaryEnabled` method is removed as unused.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
The only thing we need hashes for is to process notifications.
Balance contract if left for now, as it has some initialization.
Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>
Processors that use `invoke` package to make chain invocation should provide
fee config and client with enabled or disabled notary support. If notary
support is disabled, then functions from `invoke` package will perform
ordinary method invocation with extra fee.
Processors that use `morph/client` wrappers should check `notaryDisabled`
flag to call corresponding wrapper function.
Netmap processor omits some actions during validator syncronization
if notary is disabled.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
