Change IDTOKEN use to be more aggressive by delaying the checks
IDTOKEN authentication should be used by the Glideins if:
1. User pool collector is compatible
2. Frontend and HTCondor on Frontend are compatible
3. Factory and HTCondor on it are compatible
4. HTCondor tarball is compatible
The current proactive check may not use IDTOKENS when could be possible, e.g. the listed version of condor is misspelled or is default (because it is checking for the version number comparing the value of the variable CONDOR_VERSION.
Unless some drawback is seen in the new approach proposed below, this should change.
The token is small, so it is cheap to send it anyway, therefore the checks should be delayed as much as possible (no ahead) and fall-back to x509 should be used if something fails.
a. If the Frontend can generate the IDTOKEN is should assume that 1 and 2 are met and send the IDTOKEN to the Factory
b. If the Factory receives IDTOKEN and can forward it encrypted to the Glidein it should do so
c. condor_startup.sh (generating the condor configuration) should check the version of the condor binary and if it is compatible w/ IDTOKENs it should set in the configuration IDTOKEN as the primary authentication method. x509 can be capt as fall back (2nd in the list)