Added configurable status indicator

[eiachh]

As in the ticket added a configurable status indicator ( from config.yaml ) 2447

There is one important note ClusterInfoUpdated and ClusterInfoChanged did use different values to insert into the same template cur.User, VS data.Context, if this was intentional, then I broke it. If it was an unnoticed bug then i fixed it and now both uses the same values.

If the user messes up the configuration and the format's %s placeholders don't match the amount of fields then the default config is used.

statusIndicator:
  format: '[orange::b]K9s [aqua::]%s [white::]%s:%s:%s [lawngreen::]%s[white::]::[darkturquoise::]%s' 
  fields:
    - K9S_VERSION
    - CLUSTER
    - USER
    - K8S_VERSION
    - CPU_PERCENTAGE
    - MEMORY_PERCENTAGE

[derailed]

@eiachh Thank you Adam for taking a pass at this!!

FYI ClusterInfo/Updated/Changed delta is indeed a bug ;(

I am a bit divided on the approach, requirements and use cases...

It seems there are 2 concerns at play:

We want to customize the collapsed indicator styles (Currently canned!)
We want to customize the layout from a canned list of fields (Also currently canned!)
I think we have mechanics for both:

We should extend k9s styles object to have a views.header section where users can match the collapsed header styles to match their theme. ie header.BgColor, header.FgColor and allow for overrides ie header.k9sVersion.FgColor, header.Cluster.FgColor, etc...

We could extend the k9s config ui section with a header section ie header.collapse:true|false and header.format: string and users can customize their k9s header. Imho I think we could use an expression here parse it out ie something like:
"K9s $K9S_VERSION $CONTEXT:$CLUSTER:$K8S_VERSION -- $CPU_PERC::$MEM_PERC".
From there we could run a replace for value/style and inject into the indicator.

Another thought would be to consider the header-indicator as a view and customize the indicator in the custom views config vs doing a one off in the main configuration.

Does this make sense?

[eiachh]

I get what you are saying and its a much better solution than how I did it. I will try to implement it soonish. The only confusing part is maybe this:
"Another thought would be to consider the header-indicator as a view and customize the indicator in the custom views config vs doing a one off in the main configuration."

header indicator is already a view isn't it?
a.Views()["statusIndicator"] = ui.NewStatusIndicator(a.App, a.Styles)

[derailed]

@eiachh Ah sorry Adam! I meant we could leverage custom views config aka views.yaml. But there really not that many options to configure the header indicator....