Validate conn_type and values for extra_field_name_mapping

[josh-fell]

Related: #22607

There are a few connections which have default values for particular extra fields namely Google (extra__google_cloud_platform__num_retries: 5), Kubernetes (extra__kubernetes__in_cluster: False), and Snowflake (extra__snowflake__insecure_mode: False). Since all extra fields are available in the form data, a check is needed to only add extra fields that are germane to the connection type of the submission. Otherwise, the extras with default values could be added to a connection's URI and extra_dejson incorrectly.

For example, before this change, assuming a user submits a connection like so:

The connection data stores extra information for extra__google_cloud_platform__num_retries:

With this change, the connection data does not contain extras which are not of the same connection type as the form submission:

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragement file, named {pr_number}.significant.rst, in newsfragments.

[josh-fell]

CC @dstandish

[dstandish]

@josh-fell is this a bug introduced by 22607?

[josh-fell]

@josh-fell is this a bug introduced by 22607?

Yes, I could have been much more clear about that 🤦

[github-actions]

The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest main or amend the last commit of the PR, and push it with --force-with-lease.

[dstandish]

yeah i verified the bad behavior in 22607 thank you very much for this.
one question with if value vs if value != "" is it not the case that the form data is always string at this point?

[josh-fell]

yeah i verified the bad behavior in 22607 thank you very much for this. one question with if value vs if value != "" is it not the case that the form data is always string at this point?

Yes in the vast majority of cases except for BooleanField and IntegerField widgets.

[dstandish]

ah yes of course 🤦 damn widgets!