CSUB-347 weighted probabilistic threshold

[CAGS295]

Description of proposed changes:

Generate a fraction weighted by stake and a sample size fraction parameter.

Practical tips for PR review & merge:

• All GitHub Actions report PASS
• Newly added code/functions have unit tests
  • Coverage tools report all newly added lines as covered
  • The positive scenario is exercised
  • Negative scenarios are exercised, e.g. assert on all possible errors
  • Assert on events triggered if applicable
  • Assert on changes made to storage if applicable
• Modified behavior/functions - try to make sure above test items are covered
• Integration tests are added if applicable/needed

[github-actions]

For full LLVM coverage report click here!

[codecov-commenter]

Codecov Report

Merging #814 (a6926b3) into dev (aa81365) will increase coverage by 0.08%.
The diff coverage is 94.11%.

@@            Coverage Diff             @@
##              dev     #814      +/-   ##
==========================================
+ Coverage   78.06%   78.15%   +0.08%     
==========================================
  Files          66       67       +1     
  Lines       10601    10649      +48     
==========================================
+ Hits         8276     8323      +47     
- Misses       2325     2326       +1     

Impacted Files	Coverage Δ
...allets/offchain-task-scheduler/src/mock/runtime.rs	100.00% <ø> (ø)
primitives/src/lib.rs	93.33% <ø> (ø)
runtime/src/lib.rs	24.25% <ø> (+0.61%)	⬆️
primitives/src/vrf.rs	93.87% <93.87%> (ø)
pallets/offchain-task-scheduler/src/ocw/tests.rs	100.00% <100.00%> (ø)
node/src/main.rs	16.66% <0.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[CAGS295]

blocked by #813

[atodorov]

Added some questions around tests.

[CAGS295]

Regarding the floating points...
The use of FP is fairly limited and is only used by worker threads to decide whether submitting transactions is appropriate.
The FLOPs don't look parallelizable. There may be accuracy loss but it is precise. Given that the hardware target supports standard FP64, I don't see why it could yield different results.
Doesn't risk balances directly, on average. The corner case is missing on rewards.

Nonetheless, I tried to get rid of it. I looked into parity's PerThings implementors and rust's fixed fixed point crate but I haven't found a way yet to implement 'fixed_point.pow(fixed_point)' with logs and exponents.

Not a strong argument but, Algorand uses FP in their main consensus in the same 'sortition' use case and Algorand has a strong peer-reviewed background. Maybe the use of FLOPS in this context is justified.

Help is welcomed, this is how far I've got.

[nathanwhit]

A few comments, still looking at the floating point stuff so I'll leave comments on that later

[atodorov]

LGTM for now. I will follow up with test related changes.

[nathanwhit]

LGTM