effectful authorization header

[yurique]

(this is the first of two PRs addressing the challenge described below, link to the second one is at the bottom)

A big thing that is happening in the k8s world is the release of Kubernetes 1.21, in which BoundServiceAccountTokenVolume got graduated to beta and is enabled by default. In particular, it will be enabled and used in AWS hosted k8s.

Release notes: https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-1.21 (see the first Important banner).

In short, this means that the auth token available within the cluster (in /var/run/secrets/kubernetes.io/serviceaccount/token) will now have an expiration time.

This means that we can no longer provide a token upon creation of the KubeConfig and expect it to work (it might expire in an hour or in a minute – we don't know).

This PR introduces a change to the way KubeConfig is created (when providing a token): the user will need to provide a token inside an F[_] and the client will evaluate it every time it needs a token.

If the user wants to keep the previous behaviour, they can provide theToken.pure[F].

Most of the files here have been changed solely because KubeConfig now has a type parameter:

case class KubeConfig[F[_]] private (
    ...
    authorization: Option[F[Authorization]],
    ...

The second PR is built on top of this one and introduces more functionality related to this matter, as well as some improvements: #173

[joan38]

Thanks @yurique !