Start basic SCT support

[djc]

No description provided.

[djc]

What kind of verification needs to happen? Thoughts on a testing strategy?

[ctz]

Verification here would be a separate feature, taking a set of valid CT logs (their IDs, public keys, etc) and checking each SCT purported to come from a valid known log is correctly signed. Doing this verification is a future upki feature, mainly because tracking "valid CT logs" requires ongoing, current knowledge.

[codecov]

Codecov Report

❌ Patch coverage is 96.77419% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.78%. Comparing base (9b8b30e) to head (6eb2c59).

Files with missing lines	Patch %	Lines
src/verify_cert.rs	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #423      +/-   ##
==========================================
- Coverage   96.78%   96.78%   -0.01%     
==========================================
  Files          19       20       +1     
  Lines        3797     3952     +155     
==========================================
+ Hits         3675     3825     +150     
- Misses        122      127       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[djc]

Need to make sure to fuse the iterator if there's an unrecoverable error.

(Personally not sure I mind Result<Iter<Item = Result<_, _>>> all that much, and I don't think this API will be all that widely used?)

[ctz]

Need to make sure to fuse the iterator if there's an unrecoverable error.

(Personally not sure I mind Result<Iter<Item = Result<_, _>>> all that much, and I don't think this API will be all that widely used?)

What do you think about the opposite change -- Result<Iter<Item = Foo>>? It means it is two pass, but the error handling is much simplified as they happen up-front.

Anyway, not married to this either way.

I have one more addition to make on this PR then we can squash.

[djc]

Need to make sure to fuse the iterator if there's an unrecoverable error.
(Personally not sure I mind Result<Iter<Item = Result<_, _>>> all that much, and I don't think this API will be all that widely used?)

What do you think about the opposite change -- Result<Iter<Item = Foo>>? It means it is two pass, but the error handling is much simplified as they happen up-front.

Uh, do we allocate after the first pass, or unwrap() during the second? Neither sound all that appealing.

[ctz]

Uh, do we allocate after the first pass, or unwrap() during the second? Neither sound all that appealing.

I was thinking unwrap() -- I have dropped this commit just now.