When comparing Field.t values, avoid the conversion to bigint

[tizoc]

Explain your changes:

• For Field.compare, perform the comparison in Rust instead of converting the values to bigints to compare them. More context here

Explain how you tested your changes:
*

Checklist:

• Dependency versions are unchanged
  • Notify Velocity team if dependencies must change in CI
• Modified the current draft of release notes with details on what is completed or incomplete within this project
• Document code purpose, how to use it
  • Mention expected invariants, implicit constraints
• Tests were added for the new behavior
  • Document test purpose, significance of failures
  • Test names should reflect their purpose
• All tests pass (CI will check this if you didn't)
• Serialized types are in stable-versioned modules
• Does this close issues? List them

• Closes #0000

[tizoc]

!ci-build-me

[tizoc]

!ci-build-me

[georgeee]

I support this change: it strictly streamlines the code.

I ran a round of this fix with the ledger test-apply tool and saw performance improvement of around 10%. It might be a statistical aberration though, but looks like even if there is a performance improvement, it;'s a marginal one.

[mrmr1993]

Per the original discussion please create a rust binding that explicitly calls into_repr and use that instead.

From the comment on the rust function backing compare:

        /// users should use this `Ord` for applications where
        /// any ordering suffices (like in a BTreeMap), and not in applications
        /// where a particular ordering is required.

[tizoc]

@mrmr1993 to clarify, should into_repr() calls be added to the already existing Rust _compare functions, or what you mean is that I should add new Rust functions that use into_repr() and use that for the OCaml compare? (leaving the originals as-is)

[mrmr1993]

@tizoc either is fine, whichever you prefer

[tizoc]

Ok, just updated the existing compare functions (wanted to be sure that doing so would not have some unintended consequence).

[tizoc]

This one is included in #14599, leaving it open for now because this one is already approved and the other isn't, but they are related.

[tizoc]

This is included in #14599 which got merged already, closing.