Add atomic update operation

[EleanorRigby]

If the existing lock is in the unclaimed state we will update it with the contents of the metadata file. If no such lock is present in either the claimed or unclaimed state we add a new lock to the pool in the unclaimed state. If the lock is in the claimed state we will wait for it to be unclaimed and proceed to update it as above.

• Update existing fakes using counterfeiter
• Add fake for UpdateLock
• Add unit and integration tests
• Update README

[pivotal-issuemaster]

@EleanorRigby Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@EleanorRigby Thank you for signing the Contributor License Agreement!

[EleanorRigby]

@tobocop : Can you review this?

[jwntrs]

@EleanorRigby This looks good. Just curious, whats your use case for wanting this?

[EleanorRigby]

@pivotal-jwinters : We wanted to update the metadata in lock file. There is no way to do that atomically. Update = [Remove-->Add] done atomically

[jwntrs]

@EleanorRigby I'm more curious about the flow of the lock file, and when/how the metadata needs to get updated in your use-case. We've seen cases where people move locks to different folders representing different states (e.g. clean vs dirty env), and I'm just wondering if your use case is similar.

[EleanorRigby]

@pivotal-jwinters : It has been a while since I worked on it but if I recall correctly, we had two jobs, one for initialization of an existing/non-existing environment with new repository changes. And other was to just recreate a non-existing environment (removed by a health check job). These two jobs were causing some inconsistent state in absence of an atomic update.

@ktchen14 : can you provide more info here?