Handle Rekor sharding

[haydentherapper]

/api/v1/log/proof defaults to using the current shard when requesting consistency proofs. This will be an issue once we shard Rekor in production. As the shard changes, the consistency proof can't be calculated, because the tree size will change back down to 1 for the new shard, while the monitor will think the tree has more elements.

We should either:

• Create one monitor per shard
• Make the monitor handle multiple shards. Shard discovery would be needed, and new shards can be found with the /log API.

[haydentherapper]

Beginning work on this to get the monitor working again.

[haydentherapper]

This came up again after yesterday's sharding. Had to delete the artifact for the last successful consistency proof to make it pick up the new log.

[ret2libc]

@facutuesca isn't this done?

[facutuesca]

/api/v1/log/proof defaults to...

This issue refers to v1 sharding, we've only implemented support in v2

[ret2libc]

Do we still want to support this @haydentherapper ?

[haydentherapper]

How are we handling this in v2? Can you configure multiple log services to monitor?

We don't have to make any changes to this for Rekor v1, since we aren't planning to create a new log shard for v1.

[facutuesca]

How are we handling this in v2? Can you configure multiple log services to monitor?

Not by configuring them. We detect if the active shard changed, and we take that into account when checking the log's consistency