Bump the minimum Python version support of Deephaven to 3.9

[jmao-denver]

This upgrade is necessary, timely and should be relatively painless because

• ADBC has been released and it requires 3.9. We want to be among the first adopters.
• the ongoing ODBC integration project has a dependency on Turbodbc with a minimum Python version requirement of 3.8
• Python 3.9 has been out for over 2 years now and is already supported by other dependent Python packages of DHC including Numpy, Pandas, PyArrow, PyTorch, Matplotlib, IB, to name a few
• Python 3.7 EOL is 6 months away

The work is estimated to include primarily:

• update minimum Python version requirement to 3.9 in the build scripts or config (setup.py/setup.cfg) of all DHC Python packages'
• update all Python versions in Gradle scripts to 3.9
• update the Python version in DHC Docker base images to 3.9

[devinrsmith]

We may dovetail with updating the base images to be closer to what we actually ship (JJ recently found a difference between the fonts installed wrt our current debian base images, and the ubuntu release images we ship). Currently, our release images are based on Python 3.10.

[devinrsmith]

I'm not against bumping minimum python versions. We should remind ourselves what the support matrix for numba / numpy are, and the support timelines for the different version of python are.

That said, I also don't want to enforce minimum version bumps for "optional" features. If ADBC had a minimum python version of 3.11, I think trying to make the argument of bumping up to 3.11 would be a hard sell.

All that - we can absolutely bump up our base image to 3.9 without bumping up our "minumum python version". I've discussed elsewhere, but the best-case would be to have a matrix of python version testing.

[devinrsmith]

The integration server base images have been bumped from 3.7 to 3.10. If our production server images get bumped to 3.11 in the future, then our integration server base images will be bumped in lockstep.

I think we still need to do an exhaustive sweep of the codebase to see if there are other test setups that rely on 3.7 (or 3.8, or 3.9). And report back here.

The question still remains though:

"Should we bump our minimum supported version to 3.8? 3.9? 3.10?"

Bumping the minimum supported version will not currently effect our testing (modulu the results of the exhaustive sweep above), nor our released docker images. It will effect users who are running natively with their own python environments (https://deephaven.io/core/docs/how-to-guides/configuration/native-application/#python-environment), or users running with the embedded python server. (I suspect we may also have to take into account python environments that DHE wants / needs to support.)

As such, the "best" minimum version is the minimum version of python that our code and dependencies technically allows. I think there is also a good case to be made that we should not have any aversion to bumping python minimum version to move past EOL versions, even though they may still technically work.

Of course, bumping python versions because we want / need to use new python features, or because our required packages require newer versions of python, are legitimate reasons to bump the minimum python version as well.

Is it possible to "force" install a package, even if it "requires" a newer python version? (I'm asking, because that might be an ok solution for users who really want to use python 3.7 with Deephaven, but we want to encourage "best practices" by bumping up our minimum version without it being technically necessary.)