`eth_getLogs` slow
```
DBG 2025-01-28 17:44:07.803+01:00 Processing JSON-RPC request                id=2710 name=eth_getLogs
DBG 2025-01-28 17:44:07.949+01:00 Returning JSON-RPC response                id=2710 name=eth_getLogs len=2
DBG 2025-01-28 17:44:08.056+01:00 Received JSON-RPC request                  topics="JSONRPC-HTTP-SERVER" address=127.0.0.1:53070 len=244
DBG 2025-01-28 17:44:08.056+01:00 Processing JSON-RPC request                id=2711 name=eth_getLogs
DBG 2025-01-28 17:44:08.498+01:00 Returning JSON-RPC response                id=2711 name=eth_getLogs len=2
DBG 2025-01-28 17:44:08.608+01:00 Received JSON-RPC request                  topics="JSONRPC-HTTP-SERVER" address=127.0.0.1:53084 len=244
DBG 2025-01-28 17:44:08.608+01:00 Processing JSON-RPC request                id=2712 name=eth_getLogs
DBG 2025-01-28 17:44:56.734+01:00 Returning JSON-RPC response                id=2712 name=eth_getLogs len=10886
```

Here's a few log requests (by the CL to the deposit contract) - we can observe several things:
* even when the response is small, it takes quite long to respond, ie 100-200ms for an almost-empty response
* when there's actually datya, it takes almost a minute

Whatever else, it shouldn't take a minute to generate these.

Casual observation with a profiler and/or gdb shows hashing as the culprit - a random call stack from gdb for example:
```
(gdb) bt
#0  0x000000000062a20c in _ZN6keccak15keccakTransformE3varI5arrayI9range01995uInt8EE (
    data_p0=data_p0@entry=0x7ffc27b7bd50 "\274\357L+\227\026\021fё\017\223j2\254\031\350p\003N,KN\3467\247W\034b|o$-M_\220\227\266\fUN\032\005z>\343\246O\003\371l\035/\276\373-\277\276\323J\205\370\001\240zO\316\036\256\363\331\016\275\205\333\n\274R\217\303\017CJ\275\301Ɯ\230\273\302\3014IO\360\n\301\373|\362\310\364\222\314\034eھAzs\276\r\370K\247\210\321j\331\301v\372\342U\336;w\375\001'\257k\357\317\022-P7\365\211\r\266\231\027\303Llj<N\276\204\275\261\240\302=`\231\bF\204䶢\033\376\2556H@\327M&s8\017d\257߸\363\356\231Ԣ*\375\336:\367\344\365\257\237\244\336\024`") at /opt/nimbus-eth1/vendor/nimcrypto/nimcrypto/keccak.nim:176
#1  0x000000000062ded0 in _ZN6keccak6updateE3varI13KeccakContextI6staticI3intE6staticIN6keccak10KeccakKindEEEE9openArrayI5uInt8E (ctx_p0=0x7ffc27b7bd50, data_p1=<optimized out>, data_p1Len_0=<optimized out>)
    at /opt/nimbus-eth1/vendor/nimcrypto/nimcrypto/keccak.nim:390
#2  _ZN6hashes9keccak256E9openArrayI5uInt8E (input_p0=<optimized out>, input_p0Len_0=<optimized out>, Result=0x7ffc27b7c279 "") at /opt/nimbus-eth1/vendor/nim-eth/eth/common/hashes.nim:95
#3  0x00000000009ad698 in _ZN7filters10deriveLogsEN7headers6HeaderE3seqIN12transactions11TransactionEE3seqIN8receipts7ReceiptEE (header_p0=0x7ffc27b7ccb0, transactions_p1=<optimized out>, receipts_p2=<optimized out>)
    at /opt/nimbus-eth1/nimbus/rpc/filters.nim:38
#4  _ZN14setupServerAPI15getLogsForBlockE3refIN10chain_desc30ForkedChainRefcolonObjectType_EEN7headers6HeaderEN13eth_api_types13FilterOptionsE (chain_p0=chain_p0@entry=0x7fcb8b9b6600, header_p1=header_p1@entry=0x7ffc27b7ccb0, 
    opts_p2=opts_p2@entry=0x7fcb677bb1c0, Result=Result@entry=0x7ffc27b7cca0, ClE_0=ClE_0@entry=0x7fcb8b9e3260) at /opt/nimbus-eth1/nimbus/rpc/server_api.nim:255
#5  0x00000000009ae371 in _ZN14setupServerAPI15getLogsForRangeE3refIN10chain_desc30ForkedChainRefcolonObjectType_EE6uInt646uInt64N13eth_api_types13FilterOptionsE (chain_p0=0x7fcb8b9b6600, start_p1=<optimized out>, finish_p2=21017454, 
    opts_p3=0x7fcb677bb1c0, ClE_0=0x7fcb8b9e3260) at /opt/nimbus-eth1/nimbus/rpc/server_api.nim:273
#6  0x00000000009aea3b in _ZN22eth_getLogs_rpcHandler22eth_getLogs_rpcHandlerE3refIN7futures26FutureBasecolonObjectType_EE (chronosInternalRetFuture_p0=<optimized out>, ClE_0=<optimized out>) at /opt/nimbus-eth1/nimbus/rpc/server_api.nim:304
#7  0x000000000052e4ab in _ZN12asyncfutures14futureContinueE3refIN7futures26FutureBasecolonObjectType_EE (fut_p0=0x7fcb64d38ad0) at /opt/nimbus-eth1/vendor/nim-chronos/chronos/internal/asyncfutures.nim:371
#8  0x00000000009aff81 in _ZN14setupServerAPI22eth_getLogs_rpcHandlerEN13eth_api_types13FilterOptionsE (filterOptions_p0=<optimized out>, ClE_0=<optimized out>) at /opt/nimbus-eth1/vendor/nim-json-rpc/json_rpc/private/server_handler_wrapper.nim:182
#9  _ZN22eth_getLogs_rpcWrapper22eth_getLogs_rpcWrapperE3refIN7futures26FutureBasecolonObjectType_EE (chronosInternalRetFuture_p0=<optimized out>, ClE_0=<optimized out>) at /opt/nimbus-eth1/vendor/nim-json-rpc/json_rpc/private/server_handler_wrapper.nim:313
#10 0x000000000052e4ab in _ZN12asyncfutures14futureContinueE3refIN7futures26FutureBasecolonObjectType_EE (fut_p0=0x7fcb649fc9f0) at /opt/nimbus-eth1/vendor/nim-chronos/chronos/internal/asyncfutures.nim:371
```

`perf top` looks similar, ie hashing..

Since these are transactions from the database, it's _pretty odd_ that we're recomputing their hashes - this should have been cached somewhere to avoid the computation.
