common/gossip_store: optimize case where entries are filtered out.

[rustyrussell]

@whitslack complained of large CPU usage by connectd at startup;
I ran perf record on connectd on my machine (which sees a little spike, only)
and I see the cost of reading and discarding the entries:

-   95.52%     5.24%  lightning_conne  lightning_connectd  [.] gossip_store_next
   - 90.28% gossip_store_next 
      + 40.27% tal_alloc_arr_ 
      + 22.78% tal_free
      + 11.74% crc32c
      + 9.32% fromwire_peektype
      + 4.10% __libc_pread64 (inlined)
        1.70% be32_to_cpu

Much of this is caused by the search for our own gossip: keeping this separately
would be even better, but this fix is minimal.

[whitslack]

@rustyrussell: To be clear, it's not just at startup. lightning_connectd never settles down. I started my current Core Lightning process 171 hours ago, and lightning_connectd has used 152 hours of CPU time and is still pegging. That's an average of 88.9% CPU utilization over the lifetime of the process.

[rustyrussell]

We will do this scan every time someone reconnects: for me that's worst at startup, but if you have enough peers....

This patch should drop it by a factor of ~10. We can get more sophisticated (keep our own gossip separately for this case) but that's a more invasive change which risks introducing other bugs.

[cdecker]

This patch should drop it by a factor of ~10. We can get more sophisticated (keep our own gossip separately for this case) but that's a more invasive change which risks introducing other bugs.

That would be great for sharing/copying a single gossip file (for bootstrapping) among multiple nodes as the non-local gossip messages would not be intermingled with the public ones. 👍

[cdecker]

ACK b28adf1

[vincenzopalazzo]

ACK b28adf1

[rustyrussell]

Not sure how much this helps #5301, which this should have referred to!