Parallelize test_sql.py - Issue #60378

[dShcherbakov1]

• Closes TST: Make test_sql.py parallelizable #60378
• Builds off of TST: Make test_sql.py parallelizable  #60595
• Extends @UmbertoFasci's per-table UUID work
• Solves TST: Make test_sql.py parallelizable  #60595 concurrency issue

- [x] Parallelizes test_sql.py via per-worker_DBs (approach superseded due to complexity)

[mroeschke]

Thanks for the PR but this solution is too heavy handed.

As mentioned in the issue, the tests need to be refactored in a way to have unique table names

[dShcherbakov1]

Thanks for the feedback @mroeschke!

Having now run this through CI, I agree! I come from a production-oriented environment, so I initially underestimated the architecture/OS complexity.

I looked into per-table UUIDs as per @UmbertoFasci's PR, and was concerned it might impact future test writing, and it still had some parallelization issues. I thought that using a different approach could solve these problems, but I see the value of this approach.

I will revise this to use UUIDs on a per-test basis (building off of @UmbertoFasci's work).

[dShcherbakov1]

I'm not ready for review yet.

I added the connect_and_uuid fixture, this was the most parsimonious way I found to manage the sqlalchemy connection objects, as well as sharing the same UUIDs between tests (which create views and tables) and fixtures (which tear down views and tables). Working to extend this fixture to the rest of the tests.