Reduce TAPE Unit Test Flakiness

[wilsonbb]

After the merging of the refactor into main in #308, there seems to be some flakiness in

An example part of the error from last week's failed smoke test:

tests/tape_tests/test_ensemble.py::test_parquet_construction[parquet_ensemble_from_source]
  /opt/hostedtoolcache/Python/3.11.7/x64/lib/python3.11/site-packages/tape/ensemble.py:94: RuntimeWarning: coroutine 'wait_for' was never awaited
    self.client.close()

@dougbrn noted this could be trying to send messages to a closed client (dask/distributed#2956) caused by changes to conftest. So far have gone through all of the changes, but nothing has stood out. Will be making another pass.

[dougbrn]

I was encountering this pretty consistently on #327, the 3.9 build was failing consistently on the test_parquet_construction from hipscat, it did eventually run after ~10 restarts...

[wilsonbb]

An example of the above failure: https://github.com/lincc-frameworks/tape/actions/runs/7225142286/job/19687939027

Of particular relevance seems to be

tests/tape_tests/test_ensemble.py::test_parquet_construction[read_parquet_ensemble1]
  /opt/hostedtoolcache/Python/3.9.18/x64/lib/python3.9/site-packages/tape/ensemble.py:94: RuntimeWarning: coroutine 'wait_for' was never awaited
    self.client.close()

[dougbrn]

As of #376, this seems to be happening much less, but it's important to emphasize that the underlying issue of how clients are being shared/opened/closed is not changed at all and instead I've just made most things client-free.

[wilsonbb]

Revisiting, unit test flakiness has decreased significantly, but as noted the underlying connection issues we're seeing with client open/close are still present in the multi-ensemble context. Closing this issue as flakiness has not been a concern for a month, but #362 remains open to investigate and resolve these client issues.