Specify public key for inactive shards in shard config

[priyawadhwa]

This is pretty much the last item we need for sharding! Specify a public key for inactive shards in the sharding config in case we are rotating signers; this way users can request the public key for a specific shard from the API

cc @lkatalin and @asraa

Summary

Ticket Link

Fixes

Release Note

[codecov-commenter]

Codecov Report

Merging #746 (116282a) into main (befbcc0) will increase coverage by 0.17%.
The diff coverage is 76.92%.

@@            Coverage Diff             @@
##             main     #746      +/-   ##
==========================================
+ Coverage   48.43%   48.60%   +0.17%     
==========================================
  Files          61       61              
  Lines        5492     5518      +26     
==========================================
+ Hits         2660     2682      +22     
- Misses       2544     2546       +2     
- Partials      288      290       +2     

Impacted Files	Coverage Δ
pkg/sharding/ranges.go	53.75% <76.92%> (+11.15%)	⬆️
pkg/types/rekord/v0.0.1/entry.go	51.51% <0.00%> (+0.60%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update befbcc0...116282a. Read the comment docs.

[lkatalin]

This looks good! I had a question around the pubkey API endpoint because I don't see any documentation but maybe it's only internal?

[lkatalin]

Is this endpoint external for the user like loginfo or just internal?

[priyawadhwa]

it's external! you can query it like this:

curl "http://localhost:3000/api/v1/log/publicKey?treeID=383271703219633232"

[lkatalin]

Is that documented anywhere? Maybe I missed it.

[priyawadhwa]

I had to look at the openAPI docs here to figure out the different types of params they accept. I went with query because that's what we do for a bunch of other api calls as well (/api/v1/log/retrieve, /api/v1/log/proof etc)

rekor/openapi.yaml

Lines 113 to 132 in 035b262

	parameters:
	- in: query
	name: firstSize
	type: integer
	default: 1
	minimum: 1
	description: >
	The size of the tree that you wish to prove consistency from (1 means the beginning of the log)
	Defaults to 1 if not specified
	- in: query
	name: lastSize
	type: integer
	required: true
	minimum: 1
	description: The size of the tree that you wish to prove consistency to
	- in: query
	name: treeID
	type: string
	pattern: '^[0-9]+$'
	description: The tree ID of the tree that you wish to prove consistency for

[lkatalin]

Oh okay, thank you, I meant documented in Rekor for the user to be able to use some of these commands, but we can do that later if we want to. The link is helpful to me as I'm also trying to figure it out!

[priyawadhwa]

ah gotcha, yah docs would be useful for sure!

[lkatalin]

Also I love the e2e tests! 💯