feat: custom resource links

[thejoeejoee]

Hello!

As described in #2561, I'm proposing a solution for custom resource links.

I've got some questions during implementation:

1. internal.KeyFields from context is not taken into account in all Lister implementations -- that's intentional? I've added support to Table, makes sense to have implemented in all Lister implementations?
2. should the customResourceLinks validation respects the target cluster and validates, if the target resource exists?
3. is the name appropriate? I've chosen customResourceLinks as it's not only for custom resources, but also for built-in resources, and it's not only for relations, but also for filtering. I'm open to suggestions.

[derailed]

@thejoeejoee First off Thank you Josef for this pr.
I think this would be super useful!

It think it would be best to use the same strategy as the custom column field in kubectl. Thus I don't think it is necessary to differentiate label/field selectors since we end up with a json query anyway.
I am not super keen in overriding 'enter' as I think the default behavior might still be desirable and avoiding surprises while cruising a cluster. Not to mention there could be other fields a user might want to use to surface extended behavior ie list secrets and confimaps referenced by a given crd.

Thus I was thinking perhaps something like this could fit the bill ie pairing a key binding with the json Q to enable different actions from a given resource??

k9s:
  customActions:
  blee/v1/zorg:
  - target: v1/secrets
     description: View Secret
     action: U:metadata.labels.secret # => bind key U to show associated secret.
   - target: v1/configmaps
      description: View ConfigMap
      action: M:.spec.cm                       # => bind M to view associated cm

I also think introducing json parsing in this PR should allow us to reuse the parser logic to enable custom columns extensions.

WDT? and would this make sense?

[chivalryq]

Hi @derailed

I'm facing basically the same problem this PR proposing to solve. And here's my two cents.

1. It does make sense to support binding other keys than just <Enter>. But I'm still a fan of <Enter> which can align with the default deploy=>pod experience.

2. Field Selector Use just json query for some fields (like metadata.labels.secret) can't express the action of selecting some of these resources. To select some target resources, we need two things:

   1. Use which fields of target resource to match.
   2. Match value

   What you have proposed here

   k9s:
     customActions:
     blee/v1/zorg:
     - target: v1/secrets
        description: View Secret
        action: U:metadata.labels.secret # => match which field of target resource? Maybe name but can't be custmized.
      - ...
   

3. Label Selector There is another scenario: use labelSelector to select target resources. For example, Deployment won't list any Pods' name that belong to it.

LabelSelector is a common case when selecting. @thejoeejoee's original proposal didn't quite cover this case. I propose something like:

k9s:
  customResourceLinks:
    any.io/v1/customdeployment:
      target: v1/pods
      labelSelector: .spec.selector # JSON query that must points to a `k8s.io/apimachinery/pkg/apis/meta/v1.LabelSector`