If a state db document update to CouchDB has a http timeout
(currently defaulted at 35s), the transaction may eventually
succeed in CouchDB, but the peer will do a retry using the
previous CouchDB document revision number. The retry will
therefore fail due to revision number conflict. The peer will
think it failed, when in fact it succeeded. Peer panics when
it can't process the block to completion, since subsequent
blocks should not be processed. Need to fix retry logic to
account for this scenario, potentially by introducing a higher
level retry that could get the new revision number for a final
attempt.

Implement a retry in the couchdb SaveDoc/DeleteDoc functions to retry
if the return code is 409 (revision conflict).  If
the return code is 409, then retrieve the current revision
for the document ID and retry.   This logic is separate from
the timeout logic in handleRequest is only used for resolving
document revision conflicts caused by CouchDB timeouts.

Change-Id: I2ef79b63397a8f76e295dc7c562f5cc7f86da73d
Signed-off-by: Chris Elder <chris.elder@us.ibm.com>
Signed-off-by: David Enyeart <enyeart@us.ibm.com>