Add VersionWatcher type (for unitRelationWatcher)

Add VersionWatcher type (for unitRelationWatcher)

I am still concerned that we're doing a lot of unnecessary work for benefits
I can't see. As succinctly as possible:

* we are notified of a settings change.
* we discard the actual data and retain only the version.
* we thereby create potential state "changes" that aren't actual changes (
  IIRC ConfigNode prevents non-changes from actually being written, but I
  don't really like implicitly depending on that sort of property of
  distant code).
* when we come to execute hooks in response to that change, we look up that
  data again (which is now out of sequence wrt the relation membership).
* we also cache that out-of-sequence data to prevent us from seeing more
  changes midway through hook execution (but the settings of individual
  nodes are cached individually at the time they're first accessed, so the
  relation membership, and the settings of every node accessed during hook
  execution, are all potentially out of sync).

I accept that the out-of-sequence-ness doesn't really matter much -- and
that after enough changes we'll always hit the same steady state -- but it
seems to me that the above strategy is actually a lot more work, and harder
to follow, than the following:

* we are notified of a settings change
* we store the settings
* when running a hook in response to the change, we use the recorded
  settings

I would greatly appreciate a succinct explanation of the benefits of the
first approach over the second, because I still don't see what we (or the
charm writers) gain in exchange for all the extra code and complexity; this
would make me feel a lot more comfortable about the path down which this CL
is the first step.

https://code.launchpad.net/~fwereade/juju-core/version-watcher/+merge/111158

(do not edit description out of merge proposal)

[fwereade, 2012-06-20 07:28:21]

Please take a look.

[fwereade, 2012-06-20 08:04:47]

Please take a look.

[rog, 2012-06-20 09:44:52]

I'm not precisely clear on the issues that William is
referring to, but I can't see any need for a version
watcher that reads the content (which is what we care
about) and throws it away, keeping only the version
(which we don't care about).

[fwereade, 2012-06-20 11:13:32]

On 2012/06/20 09:44:52, rog wrote:
> I'm not precisely clear on the issues that William is
> referring to, but I can't see any need for a version
> watcher that reads the content (which is what we care
> about) and throws it away, keeping only the version
> (which we don't care about).

The issue is that the python explicitly cares only about the version, and gets
the state again later; as I've said, I think this approach is complex and
costly, and I don't see a good reason to duplicate it in the Go. I think the
final steady state is the same in both cases; the additional storage cost of
keeping complete settings rather than versions is IMO not likely to be
excessive; and it takes less code to produce a more consistent result. I don't
really see any serious upside to the version-centric approach.

[niemeyer, 2012-06-20 15:46:34]

Marking this as WIP until we find a moment to talk this through.