Service upgrade support checking

[stuartpb]

addons:upgrade goes even farther than #2 in checking not only for service existence, but for the existence of an upgrade script within that service.

I think I need to revisit the way service upgrading (and service implementation actions in general) works: I think the original idea was for an app to have an upgrade script which can take paths for doing upgrade actions in special ways for different implementations (ie. the rethinkdb service may choose to perform migration using rethinkdb containers if Docker is present, or using vendored binaries if there's a path for that, etc), rather than having implementations have their own hooks / upgrade scripts.

Meanwhile, Docker services implicitly upgrade as part of the plushu-services-docker implementation (running any Docker upgrade script at 20 and changing the image at 40).

[stuartpb]

Relevant comment from the original design dialogue: plushu/plushu-services#2 (comment)

There aren't really any conclusions there (apart from what's here), so I'm going to sift through commit messages and see if there was any deeper rationale for services-docker's design somewhere.

[stuartpb]

I didn't find anything.

What I remember of the rationale I gravitated to circa February 2015, and I guess I didn't write any of this down, but there are likely to be "things I want to happen whenever Docker upgrading happens" for every service, particularly the (relatively) complex image-and-tag-updating logic seen in https://github.com/plushu/plushu-services-docker/blob/master/hooks/upgrade-service/40_set-image, and the entire point of the services/addons system is to reduce the amount of boilerplate duplicated for each defined service, and "if Docker then do Docker upgrade stuff" was part of that boilerplate that basically any service would end up doing.

This is something I considered after the original idea of having only the root upgrade script, which is why addons:upgrade is currently still designed for it.

I think the new conclusion is that upgrade is a function of the implementing system as much as it is the addon itself (without docker/IMAGE, current services don't even have a notion of version numbers attached to the service), and so allowing / failing upgrades is something to be handled within the upgrade-service hook (sevices-docker could choose to fail upgrades to any services that don't have an upgrade script specified, but the conclusion I've come to is that it generally doesn't work that way).

[stuartpb]

What this means is running addons:upgrade foo bar baz won't pop an error, even if the command is effectively a NOP: there are already a ton of places in Plushu where things that should do something don't do anything if you don't have the requisite plugin installed (which is part of the argument driving issues like plushu/plushu-config#3, plushu/plushu-apps#6, and plushu/plushu-build-cedarish#8 for printing output to verify that something did happen).