fix(sharding): deregister queue before delete

This addresses a subtle issue in the case that a worker crashes in the
middle of a queue deletion.

Currently, the order of operations on a queue delete in a sharded
context is:

1. Delete queue from storage
2. Remove the queue from the catalogue

This is *wrong*. If a marconi server dies between 1 and 2, the system
is left in an inconsistent state. Lookups on the catalogue will still
forward operations to storage, and storage may or may not return a 500
depending on the operation performed. It's difficult to reason about.

The new proposed ordering is:

1. Remove the queue from the catalogue
2. Delete queue from storage

In this case, the failure behavior is easy to reason about. For all
operations excluding creating a queue with the same name, a 404 will
be raised, as expected. In the case of a create queue, a 204 will be
returned rather than a 201, which is functionally equivalent.

Change-Id: Ia4063305cebb1e89118cfca8efccf0b38ae41adb
Merge "fix(sharding): deregister queue before delete"