Deployment via tarball

The deployment approach is that a puppetmaster will periodically rsync new_rings.tar.bz2 from each swift_ring_manager host, and then deploy it to swift servers as rings.tar.bz2 (with suitable handling to untar this file into /etc/swift when it changes). The aim is to avoid any race conditions where e.g. .ring.bz and .builder files are deployed out of sync with each other.

So deploy_rings() now tars up the .builder and .ring.gz files from tmpdir, and then renames the tarball into swiftdir (ensuring any readers will either get entirely the old rings or entirely the new ones).

This MR includes a couple of other supporting changes - to be pickier about allowed return codes of swift-ring-builder, and to copy all rings into our tmpdir, not just modified ones.