Backend - Create new connection config type for manual webhooks

[seanpreston]

What

Add the foundation for a new ConnectionConfig type - the Manual Webhook.

Configuring

• Create a new connection config type - manual_webhook. Add API tests verifying that this type can be created. This ConnectionConfig's Secrets will eventually be the email(s) that get notified but we're holding off on sending email notifications for the time being. So for now, there are no secrets.
  
  • This will differ from the manual ConnectionConfig type in that it is not run as part of the graph, but will run before the graph is created and executed. It's more similar to our PolicyWebhooks,
  • Create a separate table, PolicyManualWebhook, this links a policy_id, a connection_config_id (of type manual_webhook), with a fields jsonb field that has the specific fields requested mapped to the DSR-friendly label. Perhaps restrict that we can only add one per ManualWebhook ConnectionConfig.
  • This is for linking the webhook to the policy, and giving us a place to store the data that should be supplied manually. manual_webhooks will not have DatasetConfigs attached to them.
  • Add an API endpoint to create PolicyManualWebhooks.
• Add a new requires_input PrivacyRequest Status
• Expose the manual connection type as a category, with the "manual_webhook" as the only subcategory

Why

The existing manual connector backend differs from the proposed manual connector UI.

#554
#571

Our current manual connector integrates with the graph, just like any other type of connector. But the proposed UI designs have the manual connector being completely separate from the graph. The proposed UI suggests that a manual connector doesn't take in inputs from other collections and doesn't supply data to dependent collections.

While the proposed UI describes a connector that isn't as powerful, its user experience is nicer. The current manual connector pauses each time to wait for manual input for each collection in both the access and erasure stages, one at a time. The proposed UI just requests a single list of fields from a system admin to upload manually and passes those directly to the user.

Assumptions

• Manual webhooks runs first, before policy webhooks and the graph execution.
• "manual_webhooks" are only supplied the initial identity data and they do not add to know identity data to be used in the graph. Their results are only uploaded directly.
• UI doesn't seem to mention manual erasures, so this is just for access data.
• UI doesn't seem to have a concept of data categories, so we don't do any filtering of categories. The values are passed as is directly to the user.

[pattisdr]

Note: as part of implementation in #1267, it didn't seem like it made sense to associate a ManualWebhook with a policy, given the lack of policy awareness in the Admin UI currently. Also DatasetConfigs and ConnectionConfigs aren't associated with Policies either, this is more related to how we filter the data or what data we erase. Since ManualWebhooks have no concept of data categories, this is another reason to not associate them with a Policy.

I just created a simple AccessManualWebhook type that associates a ConnectionConfig with "fields" that will need to be supplied for the ManualWebhook. There can only be one AccessManualWebhook created for each ConnectionConfig of type manual_webhook