Refactor: Simplify code in smaller providers

[eumiro]

Encompasses several providers. Can be split further to smaller PRs if needed.

[uranusjr]

Need a rebase and to fix the static check errors

[eumiro]

@uranusjr it looks like ruff does not like a multi-line abstract in a docstring introduced in:

8775f84

Wondering how that could get into the repo yesterday.

[uranusjr]

See dicussion in https://apache-airflow.slack.com/archives/CCPRP7943/p1692077140945959

[potiuk]

Wondering how that could get into the repo yesterday.
See dicussion in https://apache-airflow.slack.com/archives/CCPRP7943/p1692077140945959

Yes. Just to add a bit.

Airflow is very much alive and changing. All the time. And it's very much alive, which means it's very much changing.

And it means that some expectations might change mid-flight for your PR. This is why we recommend everyone to rebase-early-rebase-often - also because we are adding and modifying static checks of ours continuously and it means that users who are rebasing stuff have a chance to see that there are new expectations (there is no chance a) everyone will read all the announcements on devluist / slack b) there is no other way to introduce changes, but to well, introduce them.

We have ~ 100-140 open PRs at any given time. Last week we merged 120 PRs by 51 authors. The chance that someon's merged change wil break your PR in-progress are pretty high. This is why I recommend ABR to everyone (Always Be Rebased). Pretty much every, single time you come-back to your PR, first thing to do is to rebase it on top of the latest main.

And yes. It might mean that sometimes your PR will have to be rebased 10 times and conflict resolved/new expectations added - because of someone else's change. That's a reality we are living in. And we have no choice but embrace it, be patient and continue rebasing and resolving conflicts/failed tests.

This is also one of the reasons I recommended to split the "huge" PR you had initially into many smaller ones. Because pretty much every time you'd rebase it, you would hit another few problems resulting from other's changes being merged in,

[potiuk]

BTW. Sometimes even it happens that if someone did not rebase early and often and we merge it accidentally we have to revert it and ask the author to redo it, when it breaks something in our "main" - does not happen all the time, but it happens occassionally. so generally "Rebase-early, rebase-often" is a way to save rework and effort for everyone.