Add sqlalchemy_url property to DbApiHook class

[rawwar]

related: #38195

This PR intends to add a method get_sqlalchemy_url, which is dependent on a property named drivername that must be defined in any provider subclass that wants to generate a SqlAlchemy URI.

This PR intends to add a property sqlalchemy_url which must be defined in any provider subclass that wants to generate a SqlAlchemy URI.

Related discussions:

• fix: use sqlalchemy_url property in get_uri for postgresql provider #38831

[rawwar]

As of now, there are tests failing because 'drivername' property is not implemented in the providers. I can implement them in the subclasses in this PR itself if this approach is ok to go ahead.

[Taragolis]

I just keep part of my comment here

After start implements into the other hooks with potential usage in particular this hook. And after it implements in many (more that 50% I guess) community supported hooks we might start use it internally in DBApiHook, e.g. obtain SA Connections, pandas dataframes and others, with backward compatible logic to the previous implementation for prevent case if hook do not implements this one and for some unknown reason it work (or not) previously. So we could reduce number of potential mistakes which spread across other hooks.

24 Hooks (approx) have no idea how to use it right now that is expected that it failed. The idea is create an interface, without any implementation, and make related hooks decide whether or not implement it, if it not implemented in most providers, there is no reason to create any of implementation into the DBApiHook, it harmful and produce more problem rather than solves

[rawwar]

I just keep part of my comment here

After start implements into the other hooks with potential usage in particular this hook. And after it implements in many (more that 50% I guess) community supported hooks we might start use it internally in DBApiHook, e.g. obtain SA Connections, pandas dataframes and others, with backward compatible logic to the previous implementation for prevent case if hook do not implements this one and for some unknown reason it work (or not) previously. So we could reduce number of potential mistakes which spread across other hooks.

24 Hooks (approx) have no idea how to use it right now that is expected that it failed. The idea is create an interface, without any implementation, and make related hooks decide whether or not implement it, if it not implemented in most providers, there is no reason to create any of implementation into the DBApiHook, it harmful and produce more problem rather than solves

Thank you. That makes sense.

[rawwar]

@Taragolis , can this be merged? I can continue working on PR's to update other providers