Should we have stopSidecar retryable?

[JeromeJu]

Current Behaviour

When we stop sidecars at pod entrypoint, we are currently marking the TaskRun as failed once any Sidecar is not stopped as expected.

Expected Behaviour

We would want to examine whether it is possible to retry the stopSidecar process. This would lead to the questions:

1. What are the conditions that we want to retry? And how we could determine on such conditions?
2. Shall we simply enforce a certain # of retries on this?

Example use cases: the sideCar could not be stopped when resources hit concurrent modification error.
i.e. "Operation cannot be fulfilled on pods ; the object has been modified; please apply your changes to the latest version and try again."

/kind question

[JeromeJu]

One straightforward workaround of this for Tekton is to change the reconciler to not to return a permanent based on OptimisticLockErrorMsg. Spinning up a PR to fix, currently working on unblocking broken imports related with dependencies issue caused by #7388 & #7387 .