units can be created without a service causing cascading failures

[Jeff Pihach]

It's not clear what causes this issue but from time to time you can end up creating units which do not have their `service` property populated which causes failures in the db `addUnits` method. We should step back through this flow to ensure that the unit could never be created without a service.

[James Sapara (james-sapara)]

Stack trace:

Uncaught TypeError: Cannot read property 'service' of undefined models.js:2239
(anonymous function) models.js:2239
Y.Base.create.addUnits models.js:2238
utils.addGhostAndEcsUnits utils.js:2219
ns.ScaleUp.Y.Base.create._submitScaleUp scale-up.js:156
delegate.notifySub event-delegate-debug.js:174
Y.Subscriber.notify event-custom-base-debug.js:1333
Y.CustomEvent._notify event-custom-base-debug.js:992
Y.CustomEvent._procSubs event-custom-base-debug.js:1122
Y.CustomEvent.fireSimple event-custom-base-debug.js:1088
Y.CustomEvent._fire event-custom-base-debug.js:1070
Y.CustomEvent.fire event-custom-base-debug.js:1038
cewrapper.fn event-base-debug.js:728

[Jeff Pihach (hatch)]

James ran into this bug again and was able to reproduce it at will and was incredibly helpful in helping debug the root cause of the problem.

Issue: Add unit is trying to create a unit with the same id as a unit which already exists.

In views/utils.js:2202 the method addGhostAndEcsUnits() is supposed to supply a valid id for the new units being created. However if the service is scaled up then scaled down you could end up in a case where the number of existing units matches an existing unit's id. To fix this this method should instead determine what the next highest unit id will be according to Juju then assign that id instead.

We cannot simply scan for the highest existing id then go 1 above that because Juju may be assigning a different, higher id.