Fix Databricks provider for Airflow 2.2.x

[alexott]

The problem was caused by using ProviderInfo.is_source field that was introduced only in Airflow 2.3.0.

[potiuk]

The problem was caused by using ProviderInfo.is_source field that was introduced only in Airflow 2.3.0.

I will add a test to detect and prevent this in the future

[potiuk]

Pretty unexpected one :)

[alexott]

It's really is a one side effect of having provider in the same repo as core - you always on the bleeding edge :-)

[potiuk]

It's really is a one side effect of having provider in the same repo as core - you always on the bleeding edge :-)

Yeah. providing that you will make sure that you use the right airflow in the multi-repo case when you develop the provider. Which is one of the things that needs to be solved in order to finally split - to make the provider development experience as good as it is now without adding necessary effort on contributors (with one of the benefits - shielding the users better from thiose kind of problems while not introducing more problems) - this will be big part of the "split out providers" AIP. Hopefully in the next few months (as soon as we finish Breeze transition I will focus my efforts on that one).

Such a split however has the property that when you DO want to introduce a chnge that will span through several components (like for example current SQL unification) then it is a lot harder to coordinate such changes. That's why it's great the "comon.sql" move was done before and we also need to look if there are more things like that to extract BEFORE the split. It will be WAY harder to do simiilar moves when we split.