added registry index for fetched records and updated proof endpoints to use the log length and registry index

[calvinrp]

The registry index for a published record is going to be different than the VecLog's Node(usize) value that is required for the log inclusion proof. For now, keeping the existing pattern of using a HashMap (could be a Vec if added back in the same order) to lookup the value in memory.

To make it easier to adjust the size of the integer for the log_length and registry_index, I added a type alias RegistryIndex.

As always, suggestions appreciated. This was more of a change than I expected.

[calvinrp]

I need to investigate why it is failing on the inclusion proof on the Postgres test. Trying to reproduce.

[lann]

Looks pretty good to me, pending CI failure.

[calvinrp]

Should be good to go now.

The Postgres test failure was tricky to track down, since I thought it was failing on the inclusion of the log. It was the map inclusion proof that was failing intermittently. When constructing the proof bundle, the leafs need to be added in the exact same order as the client provided the log leafs. It was easier to enforce the ordering in Rust than mess with the diesel Rust Postgres query.

[calvinrp]

Also, updated the /fetch/logs endpoint to use logLength instead of checkpointId. Hopefully, this is not a controversial change. It should make things easier.

The updated rendered OpenAPI spec.

This PR should be compatible with the existing Postgres DB data and shouldn't require starting fresh with the Dogfood Registry deployment.

[lann]

Could you give this a pass through cargo clippy? If you use vscode you can make it the default linter with "rust-analyzer.check.command": "clippy"

[lann]

Not sure I understand the new RegistryIndex param threaded through CoreService but otherwise lgtm.