Update Globus transfer support

[tomuram]

Balsam should switch to using its own "Globus application" definition and associated "consents", because the previous model of leveraging existing GlobusCLI state is not supported.

[tomuram]

This can now be done by specifying endpoints when authenticating to Globus (through Balsam), like so:

balsam site globus-login -e ENDPOINT_ID1 -e ENDPOINT_ID2

This will fetch a user token which can be used for transferring within and between these endpoints. Note that this functionality is currently only a first implementation; we are working through auth, credential storage, and transfers between multiple endpoints possibly under different authentication realms.

The current advice, then, when using Globus transfers with Balsam, is to do the following:

• rm ~/.balsam/globus.cfg
• balsam site globus-login -e ENDPOINT_ID1 -e ENDPOINT_ID2

In future, we might have to manage a cache of tokens, but some aspects of the token/endpoint relationships is being explored with Globus.

Relevant commit: 8905b17

[tomuram]

Update: It's not necessary (and not recommended) to remove ~/.balsam/globus.cfg now before requesting a consent for an endpoint.

We now request a consent using a previously-established client_id, which adds the new consent to the existing login.

In the current mode of operation, a user will need to request consents on each machine they use. Or, more correctly, on each machine where they have a unique home directory, since we store the login info in ~/.balsam/globus.cfg. For example, ALCF systems share a home directory, so all sites running on ALCF systems will share a ~/.balsam/globus.cfg.

Relevant commit: b428b59

[tomuram]

This issue is fixed. One note: Globus contends that consents are required for GCSv5 endpoints like Eagle/Grand, but not for GCSv4 endpoints; eventually, GCSv5 should be deployed widely and this note will be irrelevant.