`MessagingConfig` creation UX updates `ApplicationConfig` vars with no submission

[seanpreston]

Bug Description

When on the new view to Configure your messaging provider, toggling the Twilio SMS radio button causes three HTTP requests to be sent:

• PATCH /api/v1/config with

  {
  "notifications": {
      "notification_service_type": "twilio_text",
      "send_request_completion_notification": true,
      "send_request_receipt_notification": true,
      "send_request_review_notification": true
  },
  "execution": {
      "subject_identity_verification_required": true
  }
  }

• PUT /api/v1/messaging/default with {"service_type": "twilio_text"}
• GET /api/v1/messaging/default/twilio_text

Fides should not:

• set default messaging to a service with no secrets
• toggle subject_identity_verification_required to True when there is no way or verify identities (because there is no messaging provider)
• especially without user confirmation

Steps to Reproduce

1. Navigate to /management/about and toggle on the feature flags
2. Navigate to /privacy-requests/configure/messaging and select each radio button, notice that on selecting Twilio SMS

Expected behavior

A reasonable expectation here is to configure these objects within Fides, and have some explicit opt-in from the user to make the other changes.

Screenshots

[adamsachs]

i just want to note that https://github.com/ethyca/fides/issues/2787 is a UI feature we know we need, and i think it would effectively resolve this problem: enabling subject identity verification would be triggered by a dedicated UI component that clearly and explicitly changes the setting, rather than being tied to the radio button click (with no real indication to the end user, which i think is ultimately causing the confusing behavior here.