Add support for public extensions in Reports.

[jhoyla]

Draft 13 adds mandatory support for public extensions in the ReportMetadata, but doesn't define any (Taskprov is (for now) a private extension). This PR adds support for rejecting unknown extensions, which is all of them.

[cjpatton]

I believe we're missing one feature: we need to resolve repeated extensions across the public and private extension fields.

[jhoyla]

I believe we're missing one feature: we need to resolve repeated extensions across the public and private extension fields.

So the spec says:

type. (For the purposes of this check, a private report extension can conflict
with a public report extension.) If so, the Aggregator MUST mark the input share
as invalid with error invalid_message.

Which I take to mean a conflict between the public and private extensions is allowed.
If I add support for taskprov as a public extension do I reject it if it appears in both places?

[mendess]

not even a nit, just a comment. I don't have a preference but instead of Vec::new() you can write vec![]

[cjpatton]

I believe we're missing one feature: we need to resolve repeated extensions across the public and private extension fields.

So the spec says:

type. (For the purposes of this check, a private report extension can conflict
with a public report extension.) If so, the Aggregator MUST mark the input share
as invalid with error invalid_message.

Which I take to mean a conflict between the public and private extensions is allowed. If I add support for taskprov as a public extension do I reject it if it appears in both places?

The intent of the text is: "if the same extension appears twice, then the report MUST be rejected - regardless of what fields the extensions appear in." In particular, if the taskprov extension appears in the public and private fields, then reject.

[cjpatton]

The code looks largely correct, though I have some suggestions for behavior changes. I think the tests need a bit of work. Also, I have some suggestions for making the code a little cleaner/easier to read.

[cjpatton]

Looks pretty good. Let's chat in our 1:1 about the necessity of the e2e tests.

[cjpatton]

I've rebased this PR and updated the capnp schema to include the public extensions field. I've also added unit tests to confirm encoding/decoding works (thanks @mendess for the help there).

[cjpatton]

Updated the commit to fix clippy

[cjpatton]

@mendess I just ran capnp id and pasted the output here. So this is really just a random ID that needs to be unique?

[mendess]

looks good to me

[cjpatton]

I see CI passing, so I'm gonna squash and merge.

[cjpatton]

Rebased on the PR @mendess merged, hoping that solves the cargo doc failure.