Pass application context to IDPF

[divergentdave]

This is a follow-up to #422 and #434 to plumb the application context through the IDPF interface, to its XOF/PRG calls.

[divergentdave]

I haven't updated the defense-in-depth section yet. Here's what I'm thinking so far.

Part of the original rationale for passing a nonce to the IDPF was to add a tweak to the fixed-key AES function, so each client uses a different AES key. This improves concrete security, see #32 (comment). I'm not clear on the details though, is the concrete security improvement against a robustness attacker?

Including application context in addition to a nonce is straightforwardly a defense-in-depth measure against attacks on robustness via offline attacks on extractability. However, we don't allow for the same sort of potentially-insecure parameterization as with Prio3 and small fields, so this isn't as big of a deal, assuming AES and the MiTCCR construction are as strong as we think. Precomputation attacks would have to pick one application context value, and thus one fixed-key AES key or TurboSHAKE domain separation input, which would prevent replaying one bad DAP report against multiple DAP tasks, for example.

[divergentdave]

Notes from today's sync: We probably don't need to say much about the defense in depth properties of this change, but we could mention that this prevents replaying a set of input shares with different application context strings. (DAP protects against this at its layer with the InputShareAAD, but it would be nice to also protect against this at the VDAF layer)

[divergentdave]

I think the existing text about "agreeing on the application context" is good enough to cover preventing replays.