synchronizer: better handle history-status mismatch

When receiving the history of an address, the client behaved unexpectedly
if either of two checks failed.
The client checked that the txids in the history are unique, and that the
history matches the previously announced status. If either failed, it
would just log a line and do nothing. Importantly, the synchronizer could
even consider itself is_up_to_date, i.e. the GUI could show the wallet is
synced.

This is now changed such that:
- if the txid uniqueness test fails, we simply disconnect
- if the history is not consistent with previously announced status,
  we wait a bit, make sure is_up_to_date is False in the meantime,
  and then potentially disconnect
See rationale for these in the comments.

related: https://github.com/spesmilo/electrum/issues/7058#issuecomment-783613084

electrum/interface.py

@@ -953,6 +953,12 @@ class Interface(Logger):
                 if height < prev_height:
                     raise RequestCorrupted(f'heights of confirmed txs must be in increasing order')
                 prev_height = height
+        hashes = set(map(lambda item: item['tx_hash'], res))
+        if len(hashes) != len(res):
+            # Either server is sending garbage... or maybe if server is race-prone
+            # a recently mined tx could be included in both last block and mempool?
+            # Still, it's simplest to just disregard the response.
+            raise RequestCorrupted(f"server history has non-unique txids for sh={sh}")
         return res
 
     async def listunspent_for_scripthash(self, sh: str) -> List[dict]: