Test kubernetes in CI

[benclifford]

This PR is a codification of what I had to do to get pytest passing for myself while trying to review other kubernetes PRs.

The bulk of the modified files are additional test markings to label which tests require a shared filesystem (between all workers and the submit side) to store working files; and which tests require file staging (as the default file staging configuration is not valid for kubernetes, due to lack of shared file system).

There is also a bugfix for default pod names being generated as invalid format (which can fixed by users by specifying an explicit prefix)

This PR can probably be merged into master in a few stages.

[benclifford]

this is failing repeatedly on this test: (at 5c55fe6)

parsl/tests/test_regression/test_226.py F
=================================== FAILURES ===================================
__________________________________ test_no_eq __________________________________
    def test_no_eq():
>       res = get_foo_x('foo').result()

(most recently with a ManagerLost... before that, I wasn't capturing enough logging to see the whole exception.

[rjmello]

This looks good . It'd also be nice to organize the k8s-related CI files in .github/kubernetes/ or something similar.

[rjmello]

I suggest we make the Python version configurable.

E.g.,

Suggested change

	RUN apt-get update && apt-get install -y python3.12 python3.12-dev
	RUN apt-get update && apt-get install -y python3.12-venv
	ARG PYTHON_VERSION="3.12"
	RUN apt-get install -y python${PYTHON_VERSION} python${PYTHON_VERSION}-dev
	RUN apt-get-install -y python${PYTHON_VERSION}-venv

[benclifford]

this is a bit weird (something to do with how python is packaged in trixie?). Normally in debian it looks like there's a single OS-level python3 available (which changes when there's a new code-named release) and it seems unusual that trixie happens to have two. certainly debian isn't traditionally set up to expect you to be able to choose a python version from the OS.

there's a couple of things that could happen: i) always use the OS-level default python3 or ii) use something like Conda to provide a much richer Python environment. Some dependencies like the ndcctools recommends being installed using conda anyway, and so maybe that's the way to go here. I don't think there's any particular reason to want to stick with the OS-level Python, as this is "an image where Parsl works" rather than "an image that looks like a particular debian version".