debathena-cupsys-config's init script fights with Upstart in Trusty

[jdreed]

On trusty, cupsd consistently fails to be running. This is due to a hilarious race condition. avahi-daemon ships an Upstart job (as of Saucy) to reload CUPS as soon as Avahi is up, however, the job doesn't check to see if CUPS is starting. CUPS takes a few seconds to shut down and reload, and the cups Upstart job now has a post-start script that loops for 30 seconds and exits 0 if it fails to run by that time. If you then call "start" again on CUPS (as we do in configure-athena-printers), Upstart sees that the job is not running (the original "start" hasn't exited yet), tries to start it again, and hilarity ensues and the boot process sits there for another 30 seconds, and then you get a system without a print spooler.

[jdreed]

 https://github.com/mit-athena/cupsys-config/pull/3

See  1332131 and  1251735. Note that shipping an Upstart job of our own might not necessarily solve this, because there's no guaranteed that CUPS wouldn't get kicked in the middle of it. I suppose one option would be an upstart job that's a 'task' with a respawn limit of 5, maybe, that is 'start on started cups', but this is is simpler for now. But if there are objections to this, I'll try the upstart route.

[jdreed]

Actually, an upstart job may be the better choice. There's a sample one here:  https://github.com/jdreed/cupsys-config/tree/upstart

The downside, is that we still need to support non-Upstart distros. There's also no good way to programmatically determine if Upstart is both installed _and_ in use (I think?). So we'd have to let dh_installinit install its compatibility shims for upstart jobs. I'm not sure what the best way is to ship both an init script and upstart job and have them both work. Thoughts?

[jdreed]

committed  ce9505455e4d8399b63510592bd291315c95b7bd (Add Upstart job; tweak initscripts) to master