Relax TranslogWriter#assertNoSeqNumberConflict

[dnhatn]

If the recovery and indexing are concurrently happening, it's possible for a replica to receive the same operation twice: one from the replication, and the other from the recovery. However, these operations are not identical because we don't store the versionType of operations in the Lucene index.

The TranslogWriter#assertNoSeqNumberConflict assertion has been tripped several times in the CCR branch since we use Lucene in peer-recovery. This commit relaxes that assertion by excluding the versionType from the check.

[elasticmachine]

Pinging @elastic/es-distributed

[dnhatn]

CI: https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+ccr+feature-branch-periodic/879/console

[bleskes]

do we still need this now that recovery ships an external version type (like replication)?

[dnhatn]

@bleskes We still need this for now. We do not convert EXTERNAL_GTE to EXTERNAL in the replication requests. Should we always use EXTERNAL in both replication and recovery?

[2018-06-27T18:39:26,830][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [node-0] fatal error in thread [elasticsearch[node-0][generic][T#4]], exiting
java.lang.AssertionError: seqNo [0] was processed twice in generation [2], with different data. 

prvOp [Index{id='1', type='test', seqNo=0, primaryTerm=1, 
version=5, versionType=EXTERNAL_GTE, autoGeneratedIdTimestamp=-1}], // <-- from replication

newOp [Index{id='1', type='test', seqNo=0, primaryTerm=1,
version=5, versionType=EXTERNAL, autoGeneratedIdTimestamp=-1}]  // <-- from recovery

[bleskes]

LGTM

[bleskes]

We still need this for now.
fair enough.

One more thing - maybe add a test for this so we won't forget external_gte again?

[dnhatn]

Thanks @bleskes and @s1monw