fix: 'gte'&'lte' need follow ASCII character set order when load leaves

[coldstar1993]

As desc in: #3423

gte, lte are compared by characters (numbers) in the ASCII character set. So here is a potential bug that it would miss some Leaf when loadTree.
For example: When we load from levelDB a tree called NULLIFIER_TREE of height 16 (i.e, 2n ** BigInt(this.getDepth()) = 65536), the runtime code is as below:

this.db
        .createReadStream({
           gte: 'NULLIFIER_TREE:LEAF:0'
           lte: 'NULLIFIER_TREE:LEAF:65536'
         });

then, you could find that many leaves whose key starts with 'NULLIFIER_TREE:LEAF:7'/'NULLIFIER_TREE:LEAF:8'/'NULLIFIER_TREE:LEAF:9' will be missed.

Please provide a paragraph or two giving a summary of the change, including relevant motivation and context.

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[PhilWindle]

@alexghr How does this compare with the solution you used in your PR?

[alexghr]

Hye, I think there's a more efficient O(1) way of determining the number of digits (in base 10) 2^n has than converting bigints to strings.

We've also got serialisation primitives in foundation that convert bigints to buffers. In a separate PR we've encoded the leaf indices as big endian hex strings (which would sort naturally)

[coldstar1993]

could u pls share me with your pr? thx

[alexghr]

Yep, the change ended up going in with this PR #3410. Here's the diff https://github.com/AztecProtocol/aztec-packages/pull/3410/files#diff-035dc3bdb3ff63fe6f604fa8895674ecf6673c3f330af5caf4b1bee34543aecfR11-R16.