compare and swap design

A resource cas has two methods: a constructor, and a method current: func -> result<option<list<u8>>, error> for reading a value of a key, with an implicit borrow of the resource as its first argument. Calling this prior to a swap doesn't seem useful - it is either a duplicate of store.get, which incurs another database operation, or it must error. Then swap: func(cas: cas, value<list<u8>>) -> result<_, cas-error> takes ownership of the resource cas, which means the method current can't be called after it - the passed in resource will no longer be available to the caller, but some new one might be given in the cas-error variant. So I don't think the constructor of cas is actually what we want, if the point is to put an optional accessor in the error.

If you switched swap to just take the borrow<bucket> and key:string instead or a cas, it wouldn't entirely solve the problem, which is that implementors need to know at the time the swap call is made whether the value from the operation will be read - otherwise they have to transfer it from the database to the implementation unconditionally, and store it until the cas resource is dropped.

Instead, we could eliminate a lot of complexity by eliminating cas-error and resource cas and just having two functions:

swap: func(bucket: borrow<bucket>, key: string, value: list<u8>) -> result<bool, store.error>;
swap-with-read: func(bucket: borrow<bucket>, key: string, value: list<u8>) -> result<tuple<bool, list<u8>>, store.error>;

Read the existing resource cas, current, and swap definitions described in this issue, then review the seven-comment discussion for a settled direction. Confirm whether the API should replace them with swap and swap-with-read; done requires an agreed design before implementation.