Merge remote-tracking branch 'origin/master' into issues/903-jdbc-deadlock-retry-window

The replay decision is asked as two questions rather than one: replayReason()
of #879 says what the failure is - it alone reads committing, partlyCommitted
and dropped - and replayableWithin(), the bounds half of replayable(), says
whether the attempt count and the window of #903 allow another. Neither
subsumes the other: a dropped connection is worth replaying and carries no
conflict class, which the class-first form of replayable() would have refused.

conflictOf() keeps the most specific class of #903 and takes the traversal of
#879, walking every chain of the failure without the suppressed links of the
release; isRetryableConflict() is that walk asked as a yes or no.