Don't use join tokens to bootstrap embedded kubelet

[twz123]

Description

When a controller bootstraps its embedded kubelet, it doesn't have to use a join token at all. Instead, it can just bootstrap the kubelet configuration using its own admin kubeconfig.

Add a new KubeconfigGetter argument to the worker start method. If running from a controller, this will simply point to the admin kubeconfig. When running as a standalone worker, this will actually be backed by the join token, if any.

Extract kubelet's CA from its kubeconfig, instead of doing it once during the bootstrapping process. This eliminates the need for another persistent flle in k0s's data directory, allows the use of arbitrary kubelet bootstrap kubeconfigs (as long as they're valid), and removes a potential panic for bootstrap kubeconfigs that don't have a cluster called "k0s".

Improve logging during kubelet config bootstrapping: Use a structured logger, remove "kubelet" from log and error messages, as that's now obvious from the context.

Remove the explicit initialization of the kubelet cert directory. This will be handled by the upstream client config loading code just fine.

Remove the join client's token type. It has to be always of type controller-bootstrap. Integrate that check into the join client creation function instead.

Introduce constants for join token auth names.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

Checklist:

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings