state;uniter: Refactor UnitSettings and hook.Info

state;uniter: Refactor UnitSettings and hook.Info

This removes the Settings field from state.UnitSettings,
and the Members field from uniter/hook.Info structs.
The first one is never guaranteed to be non-nil and
is marked for removal some time ago, but the actual
removing is a bit involved. The second one is only
kept in-memory as a cache by the hookqueue and never
serialized to disk. It's reconstructed at uniter
startup from the local disk cache and relation info.

These changes are needed in order to simplify the API
implementation of RelationUnitsWatcher, and also to
avoid pushing unnecessary data over the wire.

https://code.launchpad.net/~dimitern/juju-core/118-state-remove-unitsettings-from-relationunitschange/+merge/183700

(do not edit description out of merge proposal)

[dimitern, 2013-09-03 15:45:53]

Please take a look.

[jameinel, 2013-09-04 06:57:27]

A very nice ratio of deleted lines to added lines.
LGTM

[dimitern, 2013-09-04 09:20:42]

After live testing as recommended by William:
1. Bootstrap a local environment
2. Deploy a unit each for 2 simple charms - provider and requirer (only metadata
and a single relation)
3. Launch debug-hooks for each unit and wait (in two separate windows)
4. Add a relation between the services
5. Call relation-set on one service in joined hook, exit
6. Call relation-get on the other service in the changed hook

It seems the config changes are being propagated as expected. Did the same test
on trunk (making sure I did go install . in cmd/juju and cmd/jujud before each
bootstrap) and the results are the same. So I'm landing this.

[fwereade, 2013-09-04 11:36:15]

The critical bit the live testing may have missed was checking that caches were
cleared for changed members.

So something like:

  skip u/0 joined and changed
  skip v/0 joined
  in v/0 changed, set value=0
  in u/0 changed, get value, check == 0; set blah=0
  in v/0 changed, set value=1
  in u/0 changed, get value, check == 1

But assuming that works, LGTM, this is lovely. Thanks!

https://codereview.appspot.com/13494043/diff/1/state/relationunit_test.go
File state/relationunit_test.go (left):

https://codereview.appspot.com/13494043/diff/1/state/relationunit_test.go#old...
state/relationunit_test.go:1219: c.Assert(ch.Changed[name].Settings,
gc.DeepEquals, m)
We still need to check versions, don't we?

https://codereview.appspot.com/13494043/diff/1/worker/uniter/context.go
File worker/uniter/context.go (right):

https://codereview.appspot.com/13494043/diff/1/worker/uniter/context.go#newco...
worker/uniter/context.go:305: // overwritten.
 with the supplied values?

https://codereview.appspot.com/13494043/diff/1/worker/uniter/context_test.go
File worker/uniter/context_test.go (right):

https://codereview.appspot.com/13494043/diff/1/worker/uniter/context_test.go#...
worker/uniter/context_test.go:374: // Check that all settings remain cached.
Shouldn't we keep the behaviour above and check that u/2's cache is cleared?