Don't specify the return type; it's inherited, and the overriding method always throws an exception anyway.
Modify conflict resolution so that write back is optional. (API-breaking change.)

Instead of always writing the results of a conflict back to the database, allow the resolver to indicate whether this should take place or not.
In many situations it turns out we don't want to unconditionally write the value back:
 - Often the resolved value is going to be updated and written back anyway. Skipping the intermediate write is a win.
 - Always writing back resolved values can lead to runaway sibling chains when multiple readers access the same key.
 - Resolving conflicts is normally very cheap compared to writing back to the database. As such the cost of a write back is not necessarily worth it, performance wise.

Writeback should only be avoided if the resolver is pure/idempotent: for a given set of siblings (in any order) it should always yield the same result.
No need to explicitly qualify successful(); it's already in scope.
Use more idiomatic field extraction.
Verify that resolved siblings are not written back to the database if the resolver does not specify write-back.
Merge pull request #21 from asnare/conflict-resolver-optional-writeback

Optional writeback when resolving conflicts

This pull request changes the conflict-resolution mechanism so that writing the resolved sibling back to the database becomes optional. This is an API-breaking change, in that conflict resolvers now return a resolved sibling and whether it should be written back or not. (Previously it was always written back.)

This is a fairly crude first iteration at improving the conflict-resolution mechanism. In the future it could be improved further by delegating the decision to the driver, which could use some heuristics (eg. sibling count, amount of data read) to conditionally write the result back.

The commits themselves contain more information about the changes I've made.