Fix(fabric): Ensure that Fabric connections do not try to use a catalog once it's been dropped

[erindru]

Previously, connecting to Fabric with an invalid / nonexistent database would succeed and it would just default to the first database in the list.

It appears that Microsoft tightened this behavior up recently, causing errors like this on main:

pyodbc.InterfaceError: ('28000', "[28000] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Login failed for user '<token-identified principal>'. (18456) (SQLDriverConnect)")

This PR calls self.close() on the EngineAdapter after dropping a catalog to trigger the following behaviour:

• Fresh connections get established so any connections pointing to the dropped database are re-created
• In order for this to work, threadlocal data needs to be cleared to ensure that when connections are re-established, they use the default catalog and not the value of the target_catalog attribute which may point to the catalog that just got dropped

It's a fairly heavy-handed approach, ideally we would selectively close connections that were pointed to the catalog that just got dropped but that was a lot more effort for minimal return because Fabric is not heavily used. If it turns into an issue, it could be revisited

[erindru]

TODO: revert

[erindru]

This threw me for a while.

You can set threadlocal data without a connection, but it will only be cleared if a connection was created. This is a problem because calling close_all() and then opening a new connection will pick up old values.

I changed it so that close_all() clears all threadlocal data regardless and then added a test test_thread_local_connection_pool_attributes to prove it's working