Feature/rewarding interval updates (#880)

* Introduced rewarding_interval_nonce to contract state

* Queries for ibid.

* Mixnode demanded set size

* Routes for obtaining demanded/active mixnode sets

* Testing only demanded nodes

* Typo

* Initial state

* Feature-locking unused imports

* Generating pseudorandom (with deterministic seed) demanded mixnodes set

* cargo fmt

* Fixed tauri state

* Renamed network monitor address to the rewarding validator

* [ci skip] Generate TS types

* Notice for the future

* Transactions to begin/finish mixnode rewarding + double rewarding protection

* Validator API using new contract calls

* Removed dead code from an old experiment

* [ci skip] Generate TS types

* Removed unused import

* Renamed 'demanded' set to 'rewarded' set

* Some renaming action

* [ci skip] Generate TS types

* Fixed post-merge dependency issue in tests

* Post merge test fix

Co-authored-by: jstuczyn <jstuczyn@users.noreply.github.com>

validator-api/src/cache/mod.rs

@@ -162,6 +162,16 @@ impl ValidatorCache {
         })
     }
 
+    // NOTE: this does not guarantee consistent results between multiple validator APIs, because
+    // currently we do not guarantee the list of mixnodes (i.e. `mixnodes: &[MixNodeBond]`) will be the same -
+    // somebody might bond/unbond a node or change delegation between different cache refreshes.
+    //
+    // I guess that's not a problem right now and we can resolve it later. My idea for that would be as follows:
+    // since the demanded set changes only monthly, just write the identities of those nodes to the smart
+    // contract upon finished rewarding (this works under assumption of rewards being distributed by a single validator)
+    //
+    // alternatively we could have some state locking mechanism for the duration of determining the demanded set
+    // this could work with multiple validators via some multisig mechanism
     fn determine_rewarded_set(
         &self,
         mixnodes: &[MixNodeBond],