fix(api): Optimize memory allocation for the filter interface of JSON-RPC

[317787106]

What does this PR do?

• Optimize memory allocation for the filter interface of JSON-RPC, eth_newFilter, eth_newBlockFilter
• add config item node.jsonrpc.maxBlockFilterNum

Why are these changes required?

This PR has been tested by:

• Unit Tests
• Manual Testing

Follow up

Extra details

[waynercheung]

LGTM

[0xbigapple]

Has this default value been tested, or is there any other reference for it?

[317787106]

Yes. It has been tested for mainnet. But nile should set it as 30000 or smaller.

[waynercheung]

what about moving cache lookup outside the loop to avoid redundant queries.

Since originalBlockHash is constant, querying the cache N times in the
loop is unnecessary. Moving it outside:

• Reduces O(N) cache accesses to O(1)
• Improves performance with identical functionality
• Better error handling with fallback strategy

// Approach A: Optimal - Query the cache once outside the loop (Recommended)
final String originalBlockHash = ByteArray.toJsonHex(blockFilterCapsule.getBlockHash());

// Query the cache only once
String cachedBlockHash;
try {
    cachedBlockHash = blockHashCache.get(originalBlockHash, () -> originalBlockHash);
} catch (ExecutionException e) {
    logger.error("Getting/loading blockHash from cache failed", e);
    cachedBlockHash = originalBlockHash;  // Fallback: use the original value
}

// Use the cached result directly inside the loop
while (it.hasNext()) {
    Entry<String, BlockFilterAndResult> entry = it.next();
    if (entry.getValue().isExpire()) {
        it.remove();
        continue;
    }
    entry.getValue().getResult().add(cachedBlockHash);
}

[317787106]

It might put unnecessary blockHash into blockHashCache if filter map is empty. But it's a good suggestion

[waynercheung]

LGTM