units are not assigned transactionally

In juju.Conn.AddUnits, each unit is created and then assigned to a machine in (at least) two separate transactions; this means that unhappily-timed connection failure can create unremovable units (and hence cause services to become unremovable). (Machine creation, if necessary, is yet another transaction, and an opportunity for races, although (I think) not a route whereby we can break the system.)

I can think of two possible fixes, neither very compelling:

1) put the assignment in the same transaction (could get rather complex...)
2) allow unit.Destroy to directly remove principal units without machines (safe IF this is the only way to end up with a deployerless unit; but I'm not confident of that at this stage, and besides it's not very friendly to create useless units and expect the user to delete them herself...)

...but I think there may be scope for a small but profitable redesign. At present, the AssignmentPolicy is determined by looking at the Environ; if we were just to create the units and forget about them (on the CLI) we could trust the Provisioner (which also has Environ access) to do exactly the same things... but without races (because there's only one provisioner).

Problems:

1) Multiple provisioners, when we get them, will still race: yes, but they're going to need some sort of locking anyway; not sure this makes the problem noticeably harder.

2) More sophisticated assignment policies, when we get them, may want to be applied to whole services and/or individual units (-1 on units, myself, but it basically already exists in python via the maas-name constraint). In that case the provisioner won't be able to figure out the correct assignment from the Environ... but if we want to avoid dropped-connection problems we'll have to either bite the monster-txn bullet OR attach the assignment policy to the service explicitly... just like a constraint.

3) In fact... I can't see any effective distinction between an assignment policy and a constraint, and am therefore very suspicious of the orthogonality of this feature anyway.

Thoughts?