coco shouldn't update configs it doesn't send to the running system

[ketiltrout]

Recap of the previous endpoint bug, now fixed:

• The DUT1 endpoint indicated updating the updatable_config for both the cluster and cluster-keep-warm PersistentStates
• But the kotekan config for keep-warm didn't include the updatable_config (an oversight on our part)

With this bad coco endpoint, the program flow in coco was something like:

• Receive update from DUT1, which indicates update to both cluster and cluster-keep-warm config
• coco updates the value in the cluster PersistentState
• coco fails to update the value in the cluster-keep-warm PersistentState
• Endpoint processing fails (with result 500 Internal Server Error)

This is a problem, because coco updated the cluster state but never sent it! So, later:

• coco runs the schedule cluster config check
• cluster config check fails because coco's internal copy of the cluster config (with the new DUT1 value) differs from what is on the cluster (no DUT1 update)

So one or more of these should be done:

• coco needs to be able to guarantee that changes to its internal state get pushed to downstream endpoints
• coco separately tracks states it wants to send vs. configs it has sent
• a failure in an endpoint causes a rollback of whatever was updated by the endpoint

Not sure which of these is best.

[ketiltrout]

coco has rollback support for failed updates, but the rollback context is separate for each PersistentState. So, a failure updating cluster-keep-warm doesn't cause a rollback of the independent cluster state. cf. #35

[ketiltrout]

I think better state context management is needed.