[WIP] feat: immediate status check after apply

[karlkfi]

This change adds an immediate status check after apply using the response object. This should short-circuit waiting for the StatusPoller for objects that reconcile immediately (e.g. ConfigMaps).

Unfortunately, this won't help CRDs or Namespaces, which actually need their controller to update their status.

This PoC impl is a hack. To do ti right, we'll need to refactor the StatusPoller to expose the injected StatusReaders, otherwise the ones used after apply won't match the ones injected by the user. Alternatively, we could just have users inject a list of StatusReaders and construct the StatusPoller ourselves.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: karlkfi To complete the pull request process, please assign seans3 after the PR has been reviewed. You can assign the PR to them by writing /assign @seans3 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/kubernetes-sigs/cli-utils/blob/master/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[k8s-ci-robot]

@karlkfi: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
cli-utils-presubmit-master	f35447368d31ffad037fd955884fbb7f568d9f3b	link	true	/test cli-utils-presubmit-master
cli-utils-presubmit-master-e2e	f35447368d31ffad037fd955884fbb7f568d9f3b	link	true	/test cli-utils-presubmit-master-e2e

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository. I understand the commands that are listed [here](https://go.k8s.io/bot-commands).

[karlkfi]

I think I'm going to put this optimization on hold for now. It has both positive and negative performance impacts.

Pros:

• For objects that are immediately ready (e.g. ConfigMap, CronJob, Secret), it would speed up detection of reconciliation.
• Immediate reporting of StatusEvents might update the table printer more quickly, but usually just with "Pending", which they should already default to (I think pending is just left blank for now tho).

Cons:

• For objects that include generated objects (e.g. Deployment, ReplicaSet, StatefulSet), the status reader performs additional API calls (usually a LIST) to get the status of the generated objects.
• Immediate reconcile status lookup will almost always be not-reconciled for most objects.

I'm not sure the pros outweigh the cons.

[Liujingfang1]

I think we can apply this optimization only to the objects that are immediately ready.

[karlkfi]

I think we can apply this optimization only to the objects that are immediately ready.

We would have to have a list of status readers specific to those "always ready" objects. Right now they're buried in the StatusPoller's defaultStatusReader. I can't think of a good way to expose them without duplicating the logic in two places. Plus, the StatusReader interface requires providing a ClusterReader, which we don't want it to use. So it'd be a big hack to try to share code, even if we wanted to.

Can you think of a better way to implement it that doesn't add a bunch of tech debt?