Make Globus dependencies optional in test suite

[benclifford]

This PR makes Globus dependencies more optional:

In regular install, globus-sdk used by the very abandoned and probably untested GlobusStaging provider is now no-longer installed, which reduces the dependency footprint some.

In test installs, Globus Compute tests can be picked out or skipped using -k globus_compute. This follows the style of -k workqueue and -k taskvine used to allow Work Queue and Taskvine to not be installed.

As a consequence, the main CI workflow no longer runs the Globus Compute site tests. This PR adds a -k globus_compute local test to the Globus-specific workflow, again in the style of the Work Queue and Taskvine tests.

The GlobusStaging uses the older "not configured implies skip implies pass in CI" model of test configuration which I find personally quite distasteful; but I have not peturbed that.

Some GlobusStaging related code now imports globus_sdk later on, rather than at the top of modules, so that it will be importable even without globus_sdk. This is because we can still generate documentation without globus_sdk installed.

Relevant issues:

Debian bug #1116867 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116867#30 where @emollier comments on some Globus related packaging impeding the Debian packaging of Parsl.

Parsl issue #2218

Changed Behaviour

Dependencies will be loosened both in user installs and test environment installs - this might reveal interesting package incompatibilities although I am not aware of any.

Import-related failures in GlobusStaging will no longer appear when importing GlobusStaging, but instead will appear when that provider tries to use globus_sdk to login/perform a transfer.

Type of change

• Code maintenance/cleanup

[benclifford]

@yadudoc @khk-globus the globus compute executor test is failing with:

E                ModuleNotFoundError: No module named 'parsl.tests.test_python_apps.test_exception'

I think that means that parsl.tests.test_python_apps exists but ...test_exception does not. (otherwise the error would refer to a higher up module).

My suspicion there is that this has the wrong version of parsl installed on the endpoint, in violation of Parsl's requirement to have the same Parsl installed in the execution environment as on the submit side -- I haven't dug further into the install, though.