Support for caller-specified sensitivity when plugging in aggregates to the graph

[raprasad]

From @joshua-oss

Feature Request: Can we get support for caller-specified sensitivity when plugging in aggregates to the graph?

The SQL layer will take care of:

• a) clamping values to ensure they’re all within the specified range,
• b) bounding per-user contribution,
• c) censoring infrequent dimensions
• d) computing sensitivity

Since the core API intends to be robust against adversaries, may need some thought about how to expose this in a safe way

• @shoematem: add a flag to the privacy definition- if protect_sensitivity is disabled, accept sensitivity arguments to mechanisms

[Shoeboxam]

1. Add protect_sensitivity flag to the privacy definition. This can be done by modifying the base.proto file.
2. Add the same flag to the Analysis constructor in the bindings, and thread the bool into the function that serializes the privacy definition.
3. In the impl Expandable for proto::{x} code blocks, where x is any mechanism:
   • if the privacy_definition.protect_sensitivity bool is false, then do not replace sensitivity if it already exists.
   • bonus: validate correctness of shape of the inserted sensitivity
   • bonus: error or warn if privacy_definition.protect_sensitivity bool is true, and sensitivity has been explicitly passed in
4. In the impl Accuracy for proto::{x} code blocks, where x is any mechanism:
   • don't call compute_sensitivity like we currently do! Read sensitivity in from the arguments. Expandable has already been called, so the sensitivity argument should already exist.
5. Add an optional sensitivity argument to all of the mechanism .json files, that defaults to None.