Token Management Flexibility

[finally-fancy]

Description
Introduce a fourth token storage mechanism “Injected” which allows Busula to accept tokens from external sources like OpenMFP. In this scenario, OpenMFP manages the token lifecycle ensuring that Busula does not need to handle or store tokens directly.

Reasons
Busula currently requires a kubeconfig or token to communicate with the Kubernetes clusters. The user must provide this during cluster registration, and the token or kubeconfig is then stored in various browser storages such as localStorage, sessionStorage, or in-memory storage.

Moreover, Busula currently lacks the flexibility to allow external systems or frameworks, like OpenMFP, to inject a token directly into the UI. OpenMFP, being a UI micro-framework, is a good candidate to manage such tokens outside of Busula, reducing security risks and providing more control over the token lifecycle. This raises security concerns, as the token may be vulnerable to attacks or misuse, depending on where and how it is stored.