Make sure successful operations are correct if second search phase is fast

 In TransportSearchTypeAction we  need to increment successful ops first before we increment and compare the exit condition otherwise if we are fast we could concurrently update totalOps but then preempt one of the threads which can cause the successor to read a wrong value from successfulOps if second phase is very fast ie. searchType == count etc. This can cause wrong success stats in the search response. 

Recently this caused several test failures because we assert on correct successful shards in count / search