Add feature to skip the condor_vault_storer portion to token-push

[shreyb]

This is basically to speed up token pushing in the case that we had a service's refresh token expire and we just regenerated it using run-onboarding-managed-tokens.

In this case, we should do the following:

1. Have flag (--skip-vault-store) to skip the condor_vault_storer step to token-push
2. However, this relies on vault tokens being stored on disk correctly. We need to figure out a way to make sure that a valid state exists where a vault token can be pushed. Maybe check for existence of file where we expect it before we even try anything?
3. Then proceed with kinit and push steps

[retzkek]

Can run-onboarding-managed-tokens run the push step itself, instead of having the user do that manually?

[shreyb]

Yeah - I think that's reasonable.

[shreyb]

It occurred to me while looking at this again that since there's a lot of overlap between what this was intended to do, what @retzkek suggested, and what token-push now does. It might be cleaner to do away with the run-onboarding-managed-tokens altogether, since that currently just does the first two operations of token-push (gets kerberos ticket, condor_vault_storer, the latter in interactive mode) and doesn't do the notifications that token-push does.

The revised token-push might have the following:

• A flag --run-onboarding that makes token-push imitate the current behavior of run-onboarding-managed-tokens, by checking for only one service given (--service has to be called too), and ensuring that notifications are disabled (disableNotifications = true). Then it could exit after running the condor_vault_storer interactively, unless....
• ...A second flag --push-tokens is set. This flag would be ignored unless --run-onboarding was set, since it's redundant in the standard token-push case. If both of these flags are set, the only difference between this and the standard token-push case is that --service MUST be set, and the condor_vault_storer (vaultTokenStoreWorker) would run interactively.

Hopefully, this will also allow for the package internal/cmdUtils to shrink, since a lot of the code there is shared between token-push and run-onboarding-managed-tokens, and would thus move to the folder of token-push.

Edited to add:

It looks like if we change the signature of internal/worker.StoreAndGetRefreshAndVaultTokens to match the type func(context.Context, worker.ChannelsForWorkers), we might be able to use the existing startServiceConfigWorkerForProcessing func to start the worker and simply feed a single value of the worker.Config item into the channel.

Second edit: rather than changing the signature of internal/worker.StoreAndGetRefreshAndVaultTokens, maybe we wrap it in a second worker func, something like StoreAndGetTokenInteractiveWorker with the same function signature as StoreAndGetTokenWorker, and have the new worker func just call StoreAndGetRefreshAndVaultTokens. That way, from the client side, you're either calling StoreAndGetTokenWorker for the non-interactive case, or StoreAndGetTokenInteractiveWorker for the interactive case.

[shreyb]

I'm starting to get this mocked out now. I have the --run-onboarding and --push-tokens flag done, and I noticed some cleanup actions I want to take before opening a PR for this.