Allow nodes to specify the "[decryption] request encrypting key" for E2EE threshold decryption requests

[derekpierre]

Based over #81

Related to nucypher/nucypher#3081.

• Nodes specify the "decryption request encrypting key" when posting their aggregated transcripts; we know at this point that the node believes that all transcripts are valid
• The "decryption request encrypting key" is stored in the corresponding Participant struct for the node.

Corresponding nucypher/nucypher PR to account for extra postAggregation parameter, and extra member in Participant struct done in nucypher/nucypher#3123

[piotr-roslaniec]

From the top of my head: I don't know if we should validate this key (or how), but if we reuse requestEncryptingKey as transcript verification, then that gives us some sort of reference point to the validity of this key. Related: #77

[derekpierre]

I had the same thought of just re-using the ferveo public blinding key as the request encrypting key in nucypher/nucypher#3081. It would be efficient.

However, @cygnusv had some thoughts about using a different cryptographic scheme than ferveo, perhaps one more browser-compatible. The request and response encrypting keys (see #nucypher/nucypher#3123) should probably use the same scheme so that is a consideration for the scheme we end up using. We just haven't nailed down which one to use as yet. Across the E2EE code, I've used Umbral for now as a placeholder to change later, but we should have a conversation soon about what scheme to use. If Ferveo then this PR can replace #77 with some tweaks, if not then it would be a separate feature.