Adding a lock should reliably fail when the pool contains a lock by that name

You can get a pool into a bad state where it has a lock by the same name in both the claimed and the unclaimed state. You do this by adding a lock with a name that matches the name of an existing lock, but adding it the opposite state of claimedness from the existing lock.

For example, you if you have a pool with a claimed lock called knox, and you add an unclaimed lock called knox, it will happily create and ruin your pool.

If you try to add a lock to a pool and state that already contains a lock by that name, it will fail to add (and retry). It gives the following (obscure) output:

adding unclaimed lock: luna to pool: cf-deployment/fresh
failed to add the lock: luna! (err: exit status 1) retrying...
failed to add the lock: luna! (err: exit status 1) retrying...
failed to add the lock: luna! (err: exit status 1) retrying...
failed to add the lock: luna! (err: exit status 1) retrying...

We'd prefer it if, instead, it said something like this in both cases:

adding unclaimed lock: luna to pool: cf-deployment/fresh
failed to add lock: luna; A lock by this name already exists in this pool. retrying...

Would you be open to receiving a pull request that implemented this?

Signed-off by: @anEXPer

Start by locating the Go code that adds claimed and unclaimed locks to a pool, then reproduce the duplicate-name cases described in the issue. The change is done when either claimedness state rejects a lock name already present in the pool with the clearer error message, and the existing retry behavior is covered or verified.