impl ConstantTimeGreater and ConstantTimeLess for ConstMontyForm

[joeymich]

Implements ctutils::CtGt, ctutils::CtLt, subtle::ConstantTimeGreater, and subtle::ConstantTimeLess for ConstMontyForm.

Addresses the following TODOs in elliptic-curves (L722, L732, L764, L774)

[codecov]

Codecov Report

❌ Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.82%. Comparing base (a7f2f57) to head (50cc6c1).

Files with missing lines	Patch %	Lines
src/modular/const_monty_form/ct.rs	0.00%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1247      +/-   ##
==========================================
- Coverage   90.87%   90.82%   -0.06%     
==========================================
  Files         186      186              
  Lines       21594    21606      +12     
==========================================
  Hits        19623    19623              
- Misses       1971     1983      +12     

☔ 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]

This operation really needs to tell us about the ordering in canonical form since that's what we actually care about. The Montgomery form ordering will not reflect that.

As a trivial example, if we pick N=7 and R=10, and have values a=2 and b=3, in Montgomery form a=6 (2*10 mod 7) and b=2 (3*10 mod 7), in which case this would be the opposite ordering of what we want.

I would suggest for an initial implementation to just convert to canonical form using retrieve() before comparing.

[fjarri]

To be fair, there are cases where one needs just some reasonable ordering, for example if you want to store these numbers in a BTreeMap/BTreeSet. But it certainly can be confusing.

[tarcieri]

I don't think it makes sense to implement it in a way that doesn't match to the canonical form ordering, but I also don't actually have a use case for these comparisons.

[joeymich]

Ah, good catch, I overlooked that. I'll update the PR to compare canonical forms using retrieve().

If the user needs Ord for some collection, we could leave it up to them to define a newtype. I see we only impl Ord for the base Uint types and wrappers.