chore: uint audit part 1 (operator<<, operator>>, ror)

[suyash67]

🧾 Audit Context

Audit of the uint module in stdlib, specifically the methods: operator>>, operator<< and ror (bitwise operations).

🛠️ Changes Made

• All three methods were manually "slicing" a field element which was very error-prone. I replaced it with split_at method (wrote a generic method split_at¹ that splits a field_t at a given bit index and returns the lower and higher slices).
• Cleaned up and optimised uint constructor from byte_array and std::vector<bool_t> (resolving old TODO)
• Added static assert on width so that we restrict uint to 8, 16, 32, and 64 bits only.

✅ Checklist

• Audited all methods of the relevant module/class
• Audited the interface of the module/class with other (relevant) components
• Documented existing functionality and any changes made (as per Doxygen requirements)
• Resolved and/or closed all issues/TODOs pertaining to the audited files
• Confirmed and documented any security or other issues found (if applicable)
• Verified that tests cover all critical paths (and added tests if necessary)
• Updated audit tracking for the files audited (check the start of each file you audited)

📌 Notes for Reviewers

Please review the split_at function carefully, and check if we are testing it thoroughly. We're soon going to remove the function slice(msb, lsb) from field_t since we no longer need it (used only in logic module). Instead, the new function split_at will replace the use of slice in logic module:

aztec-packages/barretenberg/cpp/src/barretenberg/stdlib/primitives/logic/logic.cpp

Line 99 in 6434f31

field_pt b_slice = b.slice(static_cast<uint8_t>(num_bits - 1), 0)[1];

will be changed to:

field_pt a_slice = a.split_at(0, num_bits).second;

Note: we are not going to merge any PRs that change anything in field or bigfield as they're undergoing external audits at the moment. Thus, this PR will be merged after the external audit of field (and its fixes) are done.

Footnotes

1. The existing slice(msb, lsb) method could be used but there were three issues in doing so:
   (a) found a bug in range-constraint on the hi limb in it,
   (b) slice(...) returns three limbs: hi, mid and lo so it naturally requires three range constraints. We only need two parts of a field element.
   (c) slice(...) assumes a 252-bit field element which results in (unnecessary) costly range-constraints. We'd have to change the function to accept num_bits as a parameter (or template parameter). ↩

[iakovenkos]

nice! I can re-use it in byte_array byte decomposition method

[iakovenkos]

is it possible to produce a failure test with the current circuit design?