Add lock.clj to jepsen.tests

[mkcp]

I intend to implement a lock workload for jepsen.consul at some point in the upcoming months, e.g. https://github.com/jepsen-io/etcd/blob/master/src/jepsen/etcd/lock.clj

Looking at https://github.com/jepsen-io/jepsen/tree/master/jepsen/src/jepsen/tests we don't have this abstracted out into a workload yet. I will probably get to this at some point on my own, but if someone wants to beat me to it, it could be a good chance to contribute to jepsen. Happy to walk through the process of converting a db-specific test into a workload.

[mkcp]

Looking to give watch.clj the same treatment, lmk if these additions would be valuable @aphyr and I can split out a new ticket for watch and spec it out a bit more.

[aphyr]

I support this! There are two distinct ways we test locks in etcd--one is by analyzing separate lock and unlock operations using knossos, and the other is by having each operation be an "atomic" operation mutating some in-memory data structure, and detecting concurrency violations implicitly on that object. I think the former is really all you need to show unsoundness, but the latter gives better quantitative estimates of the potential for write loss.

Also be advised that the watch and lock tests are kind of a mess in the etcd test because they're conforming to a very particular way that etcd manages locks--you can definitely pull out the generator and checker, but the client details might be Real Etcd Specific. Not sure how much is useful to extract there.

[aphyr]

Watch, in particular, embeds an AWFUL hack around convergence which I would really prefer didn't exist lol