lock on a separate/safe object rather than DaemonSet

Current locking approach requires the kured job to have the RBAC privilege to be able to update its own DaemonSet. This means a compromised kured job could redefine itself to (eg) elevate host access further(*).

Better (from an RBAC pov) would be to use a "harmless" resource type to store the lock annotation. A ConfigMap (empty/dedicated for this purpose) would be ideal.

(*) I acknowledge that kured also needs other scary privileges (patch nodes) in order to conduct a drain/uncordon, and these won't be improved by this suggestion. Small steps.

The issue names no files, tests, or entry points. Start by tracing how kured currently stores its lock on the DaemonSet and which RBAC permissions support that operation. Evaluate a dedicated ConfigMap as the lock resource, with completion requiring the lock and RBAC behavior to work without updating the DaemonSet.

Written by the indexing model from the issue text.