Added get_extra_dejson method with nested parameter in Connection

[dabla]

This new method allows you to specify if you want the nested json as string to be also deserialized. The already existing extra_dejson property delegates to this method with nested set to False, as this is the default behaviour (nested json strings don't get deserialized by default). This is a PR in preparation of #35591, as it has become to big, we're going to split it up in smaller ones. This is one of them.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an 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 newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[Taragolis]

This new method allows you to specify if you want the nested json as string to be also deserialized.

I don't think we need to support string-JSON into the native JSON object.

This one more convenient way to define JSON

{
    "foo": "bar",
    "spam": {"egg": 1, "baz": "qux"}
}

Rather this one. Which looks artificial and ugly

{
    "foo": "bar",
    "spam": "{\"egg\": 1, \"baz\": \"qux\"}"
}

[dabla]

This new method allows you to specify if you want the nested json as string to be also deserialized.

I don't think we need to support string-JSON into the native JSON object.

This one more convenient way to define JSON

{
    "foo": "bar",
    "spam": {"egg": 1, "baz": "qux"}
}

Rather this one. Which looks artificial and ugly

{
    "foo": "bar",
    "spam": "{\"egg\": 1, \"baz\": \"qux\"}"
}

We’ll need it for PR 35591, as there we split the values being put in extra into different textareas for the http connection, leading to those ugly nested json values in the extra field (which will be hidden).

[Taragolis]

Maybe we should fix it in the UI side rather than try to create workaround?
Connection UI itself provided by FAB, there is unlikely would be FAB in Airflow 3.0.

[dabla]

Maybe we should fix it in the UI side rather than try to create workaround? Connection UI itself provided by FAB, there is unlikely would be FAB in Airflow 3.0.

Indeed, but I don't know if the issue is related to FAB or the CodeMirror widget for the textarea's. To me this was the "cleanest" approache to solve the issue

[dabla]

Maybe we should fix it in the UI side rather than try to create workaround? Connection UI itself provided by FAB, there is unlikely would be FAB in Airflow 3.0.

Waht are we going to do about this one? Fixing the Javascript issue won't be easy I think, I don't know where to begin if it's related to FAB (which will probably be gone in 3.0). To me personally, this solutions isn't that ugly, ok it's a by-passing a Javascript issue that might be gone in the future unless it's related to the CodeMirror widget but there there is also a new main version released which isn't yet used in Airflow. I also prefer to see a generic/re-usable solution than to code a specific work around in the HTTP Connection/Hook class. Without this, I won't be able to continue working on the original PR 35591, which also solves the ability to specify a different HTTP authenticator class.

[dabla]

We could put a TODO remark on that method and state that if the javascript issue would be solved, this one could be simplified.

[potiuk]

Let me rebase and rerun tests to see if nothing changed since.