Fix compatibility with distributed >= 2022.5.1 and traitlets >= 5.2.0, and raise the lower bound of required versions

[consideRatio]

Closes #571.

I've observed a flurry of issues that created a very hard to debug situation, but this resolves them all I think. This patch makes us require modern versions of distributed, traitlets, click, and dask though. Unless we have tests against the minimum required versions, I think its better that we do this than hope a version could be slightly lower without issues though.

---

The click issue as seen on a scheduler pod starting and quickly terminating.

Traceback (most recent call last):
  File "/srv/conda/envs/notebook/bin/dask-scheduler", line 8, in <module>
    sys.exit(go())
  File "/srv/conda/envs/notebook/lib/python3.9/site-packages/distributed/cli/dask_scheduler.py", line 216, in go
    check_python_3()
  File "/srv/conda/envs/notebook/lib/python3.9/site-packages/distributed/cli/utils.py", line 39, in check_python_3
    from click import _unicodefun
ImportError: cannot import name '_unicodefun' from 'click' (/srv/conda/envs/notebook/lib/python3.9/site-packages/click/__init__.py)

[consideRatio]

When we don't have distributed pinned below 2022.5.0, we get:

When we don't have traitlets pinned below 5.2.0, we get:

[consideRatio]

It seems that in distributed 2022.05.1, dask/distributed#6363 was introduced, and that removes a fast parameter from scheduler.close(). So, dask-gateway must use <=2022.05.0 and we should require >=2022.05.1 after we adjust to this removal.

[consideRatio]

Traitlets 5.2.0

Traitlets 5.2.1

Broken in a way specific to 5.2.1, fixed in 5.2.2.

Traitlets 5.2.2.post.1

Same as 5.2.0.

[TomAugspurger]

Haven't looked closely here, but linking to dask/distributed#6561. With that PR to distributed, we can perhaps avoid changing the dask / distributed requirements. The current release will still be incompatible distributed=2022.5.2, but the current release will be compatible with older and newer versions (with these changes, it'll be compatible with those versions plus distributed=2022.5.2)

[consideRatio]

EDIT: Compromise suggestion in #573 (review). My concern relates to #539.

---

It adds maintenance burden to ensure that things work with old versions, so keeping an old lower bound that we don't test doesn't feel great.

What should be done ideally, is to run tests against the oldest versions declared support for, like done in jupyterhub: https://github.com/jupyterhub/jupyterhub/blob/f6eec29aa222276ea8a9d8066eabb53e9f65b1a7/.github/workflows/test.yml#L132-L159. If that is done, it seems more acceptable to me to retain an old lower version bound. But of course, this adds maintenance burden - especially if we add such tests with very old lower bounds that are around for historical reasons.

I have worked very hard to reduce the complexity of this project's many separate dependencies, reducing complexity has been critical for the maintenance sustainability. Due to that it feels troublesome to add in >=X,!=Y,!=Z where X is very old and untested. This project has so many sets of different extra_requires for the packages, a client side, server side, and docker images with dependencies getting fixed during build - I think now is a good time time to bump X to a new version.

If you don't think retaining support for a broad version range is quite important, I suggest we still make dask-gateway require a modern version of these dependencies to reduce our maintenance burden and help users end up with something more likely to work, even if it means they are forced to make some updates.

[consideRatio]

@TomAugspurger I'd like to go for a release and get this resolved today if possible, is #573 (comment) reasonable to you?

[TomAugspurger]

Looks good thanks.