[Feature] Add trace_filter RPC method support

[Emosaddd]

Problem/limitation At Hand

Harmony's JSON-RPC API currently supports trace_block but not trace_filter. This creates a severe performance bottleneck for indexing services that need to scan Harmony's transaction history.

The scale of the problem is significant:
Harmony is currently at block 87,625,513 (0x5359329). With only trace_block available, an indexer must issue one RPC call per block — or batch them, but even large batches of trace_block calls result in massive JSON payloads that cause upstream proxies to return 502 Bad Gateway errors due to body size limits.
To scan 87 million blocks using trace_block at a batch size of 500 blocks/request:
174,000+ HTTP requests required
Each request returns full trace data for every transaction in every block, regardless of relevance
At ~5s per batch: ~243 hours (~10 days) just for initial sync

Verified current state:

trace_filter → {"error": {"code": -32601, "message": "the method trace_filter does not exist/is not available"}}
trace_block  → works (returns traces per block)
eth_getLogs  → works (but doesn't cover internal/contract-creation transactions)

Which component?

• node script

Proposed Solution

Implement the trace_filter RPC method following the OpenEthereum/Parity trace_filter specification:
https://openethereum.github.io/JSONRPC-trace-module#trace_filter

{
  "method": "trace_filter",
  "params": [{
    "fromBlock": "0x1000000",
    "toBlock":   "0x1003E80",
    "toAddress": ["0xYourContractAddress"],
    "count": 100
  }]
}

This allows indexers to:
Query a block range in a single RPC call instead of N calls
Filter by fromAddress / toAddress to return only relevant traces
Use after + count for pagination within large ranges
At 10,000 blocks per request, the same 87M block history requires only ~8,750 requests — a 20,000x reduction in RPC call count.

Alternatives Considered

Additional Context

Harmony Shard 0: block 87,625,513, chain ID 1666600000
RPC tested: https://a.api.s0.t.hmny.io