interface: _search_headers_backwards: start at small delta

- interface.tip is the server's tip.
- consider scenario:
  - client has chain len 800_000, is up to date
  - client goes offline
  - suddenly there is a short reorg
      e.g. blocks 799_998, 799_999, 800_000 are reorged
  - client was offline for long time, finally comes back online again
  - server tip is 1_000_000, tip_header does not connect to client's local chain
  - PREVIOUSLY before commit, client would start backwards search
    - first it asks for header 800_001, which does not connect
    - then client asks for header ~600k, which checks
    - client will do long binary search to find the forkpoint
  - AFTER commit, client starts backwards search
    - first it asks for header 800_001, which does not connect
    - then client asks for header 799_999, etc
- that is, previously, on average, client did a short backwards search, followed by a long binary search
- now, on average, client does a longer backwards search, followed by a shorter binary search
  - this works much nicer with the headers_cache
  (- and thomasv said the old behaviour was not intentional)

electrum/interface.py

@@ -1172,11 +1172,11 @@ class Interface(Logger):
         await self._maybe_warm_headers_cache(
             from_height=max(0, height-10), to_height=height, mode=ChainResolutionMode.BACKWARD)
 
+        delta = 2
         while await iterate():
             bad, bad_header = height, header
-            delta = self.tip - height  # FIXME why compared to tip? would be easier to cache if delta started at 1
-            assert delta > 0, delta
-            height = self.tip - 2 * delta
+            height -= delta
+            delta *= 2
 
         _assert_header_does_not_check_against_any_chain(bad_header)
         self.logger.info(f"exiting backward mode at {height}")