Filter custom_headers from destination-type schema when feature is disabled

[alexluong]

The GET /api/v1/destination-types endpoint always returns the custom_headers field in config_fields for webhook providers, even when PORTAL_ENABLE_WEBHOOK_CUSTOM_HEADERS is false. Currently, filtering only happens client-side in the Portal UI. The backend schema should omit the field entirely when the feature is disabled so API consumers don't see an unsupported field advertised in the schema.

[alexbouchardd]

Thinking back to this, I think we need to discuss the right approach. Currently, you can't actually disable the custom_headers, and you could make the argument that the clients can just omit it instead of disabling the feature. However, because the schemas are sent to the client, you end up having to filter it out and code exceptions for specific destination types.

So either we keep it as is, or move the config to DESTINATION_WEBHOOK_DISABLE_CUSTOM_HEADERS (or ENABLE...)

Should it be opt-in or opt-out?

[alexluong]

I wonder what use case would people prefer to disable this feature?

[alexbouchardd]

Fair, let's bench until we get some feedback if any