lean on stable Ordering repr(i8)

[cosmicexplorer]

• Context: In define and implement ConstantTime{Partial,}Ord traits dalek-cryptography/subtle#98 (comment) I make the case to the subtle crate that libsignal can remove our hand-rolled constant_time_cmp() if they support ConstantTimeOrd upstream via my change.
• While implementing that for the subtle project, I learned that you can lean on Ordering having repr(i8) to avoid uses of match. In define and implement ConstantTime{Partial,}Ord traits dalek-cryptography/subtle#98, this is used to impl subtle::ConditionallySelectable for Ordering by delegating to the impl for i8.
• It turns out we can avoid a match here too in libsignal's FFI method to compare public keys, since our encoding of Ordering into i<whatever> in ECPublicKey_Compare matches the one from the rust stdlib.

[jrose-signal]

This is correct, and shorter, but I'm not sure it's better. It is the case that Rust orderings have the raw representations we want here (the ones established by memcmp oh so long ago), but you had to write down a comment to say that, because it's not exposed in the docs (even though it is in the source, and stable). The compiler should absolutely optimize the first into the second anyway, but it doesn't quite today??. I'll file a Rust bug about that.

EDIT: rust-lang/rust#106459

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to inactivity.