[Feature]: Developer can switch to a different CF API via `cf api`

[gcapizzi]

Blockers/Dependencies

• [Feature]: Developer can target a cf-k8s foundation via cf api cf-k8s-api#10
• [Feature]: Developer can cf login to a cf-k8s foundation cf-k8s-api#56

Background

When switching from an API to the other, the CLI deletes the user authentication tokens so that the user is effectively logged out. When working against cf-k8s, the equivalent of those tokens is the reference to the auth-info in use, which in turn allows us to retrive the tokens/certs. When switching to a different API, this information should be deleted too.

Acceptance Criteria

GIVEN I am logged into a cf-k8s API (e.g. I have selected an auth-info)
WHEN I run cf api against a different cf-k8s API
THEN I see something like this in $CF_HOME/config.json:

"CFOnK8s": {
    "Enabled": true,
    "AuthInfo": ""
}

GIVEN I am logged into a cf-k8s API
WHEN I run cf api against a traditional CF API
THEN I see something like this in $CF_HOME/config.json:

"CFOnK8s": {
    "Enabled": false,
    "AuthInfo": ""
}

Dev Notes

There's a couple of ways we can achieve this.

• One way is to add the Kubernetes specific behaviour to the existing one, as we know they're not going to interfere. This is what we do in the spike (although the functionality discussed in this story would be achieved by changing the SetTarget method, not ClearTarget).
• Alternatively, we could consider adding a ClearTokenInformation method to the Config interface and have separate implementations. This would be more elegant but we would end up with an asymmetry: ClearTokenInformation would be used to undo SetTokenInformation in one case and to undo SetKubernetesUser in the other.

[gcapizzi]

PR