Replace ConstChoice with ctutils::Choice

[tarcieri]

Depends on RustCrypto/utils#1266

Extracts all of the const fn constructor and predication/selection methods used by crypto-bigint into the ctutils crate, allowing the ConstChoice type to be removed and replaced by ctutils::Choice.

[codecov]

Codecov Report

❌ Patch coverage is 93.70079% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.13%. Comparing base (1114f7c) to head (275cca2).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/ct.rs	85.71%	16 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1035      +/-   ##
==========================================
- Coverage   79.23%   79.13%   -0.10%     
==========================================
  Files         164      165       +1     
  Lines       17707    17616      -91     
==========================================
- Hits        14030    13941      -89     
+ Misses       3677     3675       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tarcieri]

Benchmark-wise there are several things down in the 3-5% range which seems like noise (also several things up in a similar range), but I'll highlight some weird ones with bigger deltas and then double check if they're reproducible:

Boxed Montgomery arithmetic/lincomb_vartime, BoxedUint*BoxedUint+BoxedUint*BoxedUint
                        time:   [17.844 µs 17.950 µs 18.091 µs]
                        change: [+32.845% +34.706% +37.077%] (p = 0.00 < 0.05)
                        Performance has regressed.

Here's one where the performance impact was allegedly only for one limb size:

wrapping ops/div, I2048/I1024, full size
                        time:   [2.1789 µs 2.1979 µs 2.2236 µs]
                        change: [+8.4198% +15.979% +25.465%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 18 outliers among 100 measurements (18.00%)
  6 (6.00%) high mild
  12 (12.00%) high severe
wrapping ops/div, I4096/I2048, full size
                        time:   [6.4609 µs 6.4945 µs 6.5413 µs]
                        change: [+0.4732% +1.6890% +2.8631%] (p = 0.00 < 0.05)
                        Change within noise threshold.

This is the worst offender:

modular ops/invert_mod2k_vartime, U256
                        time:   [16.349 ns 16.684 ns 17.046 ns]
                        change: [+79.583% +96.132% +110.35%] (p = 0.00 < 0.05)
                        Performance has regressed.

[tarcieri]

Upon looking at these cases again, I'm not worried about any of them in particular.

lincomb_vartime

I ran this one again on master and again on this branch.

master was improved 3% and this branch showed a ~6% drop on a subsequent run:

Boxed Montgomery arithmetic/lincomb_vartime, BoxedUint*BoxedUint+BoxedUint*BoxedUint
                        time:   [18.260 µs 18.512 µs 18.838 µs]
                        change: [+3.3629% +5.6486% +8.5372%] (p = 0.00 < 0.05)
                        Performance has regressed.

It does seem like this is potentially slower on this branch, but probably not 34% slower as the first run showed.

wrapping_div

I reran this on this branch (i.e. comparing two runs on the same branch) and it magically improved:

wrapping ops/div, I2048/I1024, full size
                        time:   [2.1453 µs 2.1502 µs 2.1550 µs]
                        change: [−19.186% −13.305% −7.8624%] (p = 0.00 < 0.05)
                        Performance has improved.

...so this seems like a fluke.

invert_mod2k_vartime

It seems like this benchmark is all over the place. I reran it on master and it was much slower, then reran it on this branch and:

modular ops/invert_mod2k_vartime, U256
                        time:   [8.4091 ns 8.6510 ns 8.9115 ns]
                        change: [−14.120% −9.4962% −4.9961%] (p = 0.00 < 0.05)
                        Performance has improved.

...so that shows an "improvement" over master. I'm going to chalk this one up to too much variance in the benchmark itself.