state: add additional test for machine.InstanceId

state: add additional test for machine.InstanceId

For reasons I don't understand the PA is not seeing the
InstanceId's recorded by previous runs. I wrote this test
to verify the behavior does work, so it should probably 
make it into the tree.

https://code.launchpad.net/~dave-cheney/juju-core/go-state-machine-id-fix/+merge/109550

(do not edit description out of merge proposal)

[dave_cheney.net, 2012-06-11 01:30:45]

Please take a look.

[fwereade, 2012-06-11 08:06:57]

https://codereview.appspot.com/6305081/diff/1/state/state_test.go
File state/state_test.go (right):

https://codereview.appspot.com/6305081/diff/1/state/state_test.go#newcode255
state/state_test.go:255: // scoped to ensure vars aren't reused.
I'm not sure this really helps, does it?

https://codereview.appspot.com/6305081/diff/1/state/state_test.go#newcode257
state/state_test.go:257: st, err := state.Open(s.zkInfo)
Why do we need a separate connection to verify this behaviour?

[niemeyer, 2012-06-11 18:20:01]

https://codereview.appspot.com/6305081/diff/1/state/state_test.go
File state/state_test.go (right):

https://codereview.appspot.com/6305081/diff/1/state/state_test.go#newcode251
state/state_test.go:251: func (s *StateSuite)
TestMachineSetInstanceIdIsPersistent(c *C) {
This is a pretty awkward test. We have a SetInstanceId test above, verifying
that it works. Why would this not work?

If this was ever broken, we need a better explanation of what this is really
verifying. If it's not broken, we already have tests verifying that
SetInstanceId works above.

The "reuse of variables" below also smells like mirrors and shadow. Reusing a
variable name shouldn't cause code to misbehave, unless the compiler has a bug.