Support knative installed by operator

[xliuxu]

Here is the spec of the knative serving CR

kubectl explain KnativeServing.spec --recursive=true 
KIND:     KnativeServing
VERSION:  operator.knative.dev/v1alpha1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec defines the desired state of KnativeServing

FIELDS:
   cluster-local-gateway    <Object>
      selector  <map[string]string>
   config   <map[string]map[string]string>
   controller-custom-certs  <Object>
      name  <string>
      type  <string>
   high-availability    <Object>
      replicas  <integer>
   knative-ingress-gateway  <Object>
      selector  <map[string]string>
   manifests    <[]Object>
      URL   <string>
   registry <Object>
      default   <string>
      imagePullSecrets  <[]Object>
         name   <string>
      override  <map[string]string>
   resources    <[]Object>
      container <string>
      limits    <Object>
         cpu    <string>
         ephemeral-storage  <string>
         memory <string>
         storage    <string>
      requests  <Object>
         cpu    <string>
         ephemeral-storage  <string>
         memory <string>
         storage    <string>
   version  <string>

According to https://github.com/knative/operator/blob/master/docs/configuration.md#specconfig, for knative installed by operator, we only need to add customized configmap data into the .spec.config field of KnativeServing CR.

We have done the detection in https://github.com/knative-sandbox/kn-plugin-admin/pull/5. Now we need to wire the changes for domain/autoscaling update commands. For get command I think we are safe to retrieve directly from configmaps instead of from KnativeServing CR as they will eventually reflect into coressponding configmaps.

[zhanggbj]

/assign @lanceliuu

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.