self-driving reflector + signal handling

[clux]

fixes #151 and fixes #152 with tokio::signal and a futures::select call.
drops a lot of Reflector logic to defer to Informer.

Also changes the api of Informer and Reflector to have clean constructors:

• Reflector::new(api).params(lp)
• Informer::new(api).params(lp)

Seems to work pretty well, but may need to deal with desyncs better.
Ran into the unordered resourceVersion issue on a really old namespace.
Need to double check if that can happen with old version.

The examples that are converted herein seem to work fine. Signal handler also works.

[clux]

Seems like re-using Informer is the source of the new resourceVersion issues. Not sure why this is, Informers function perfectly well on their own? EDIT: NOT TRUE. Reproduced the same problem with a configmap_informer in an old namespace. Every poll after the first causes a 410 Gone desync.

Ok, seems the list + watch from the list point is more resilient than the event stream..

From k8s docs:

When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code 410 Gone, clearing their local cache, performing a list operation, and starting the watch from the resourceVersion returned by that new list operation. Most client libraries offer some form of standard tool for this logic. (In Go this is called a Reflector and is located in the k8s.io/client-go/cache package.)

So, will revert the Informer dependency I guess.

[clux]

Will revert the resourceVersion parsing, even by doing that, it's not solving the problem. Informer and Reflector has to list on old namespaces #219.

[clux]

K. Reverted that part of it for now. Now this pr is just a fix of #151 and #152