Add surfacing watch error handler alternative

Author: kevindelgado

designs/conditional-controllers.md

@@ -87,8 +87,16 @@ summarization of these discussions are presented below.
   wants to support these changes, and even if they were on board, it could take
   a long time to land these changes upstream.
 
-* TODO: Bubbling up errors from apimachinery.
-
+* Surfacing the watch error handler from the reflector in client-go through the
+  informer. Controller-runtimer could then look for specific errors and decide how to
+  handle it from there, such as terminating the informer if a specific error was
+  thrown indicating that the informer will no longer be viable (for example when
+  the resource is uninstalled). The advantage is that we'd be pushing updates
+  from the informer to the manager when errors arise (such as when the resource
+  disappears) and this would lead to more responsive informer shutdown that doesn't
+  require a separate watch mechanism to determine whether to remove informers. Like
+  de-registering EventHandlers, the downside is that we would need api-machinery to
+  support these changes and might take a long time to coordinate and implement.
 
 ### Minimal hooks needed to use informer removal externally
 
@@ -103,13 +111,18 @@ The proposal to do this is:
 or not and use this field to not empty the controller’s `startWatches` when the
 controller is stopped.
 
+A proof of concept for PR is here at
+[#1180](https://github.com/kubernetes-sigs/controller-runtime/pull/1180)
+
 #### Risks and Mitigations
 
 * We lack a consistent story around multi-cluster support and introducing
   changes such as this without fully thinking through the multi-cluster story
-  might bind us for future designs. We think that restarting
-  controllers is a valid use-case even for single cluster regardless of the
-  multi-cluster use case.
+  might bind us for future designs. We think gracefully handling degraded
+  functionality in informers we start as end users modify the cluster is a valid
+  use case that exists whenever the cluster administrator is different from the
+  controller administrator and should be handled irregardless of its application
+  in multi-cluster envrionments. 
 
 * [#1139](https://github.com/kubernetes-sigs/controller-runtime/pull/1139) discusses why
 the ability to start a controller more than once was taken away. It's a little