Bug/skale 5059 limit number of filters per ip

[dimalit]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 55.14403% with 109 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.36%. Comparing base (dc82869) to head (40cba16).
⚠️ Report is 4654 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1062      +/-   ##
===========================================
+ Coverage    50.07%   50.36%   +0.28%     
===========================================
  Files          295      295              
  Lines        35533    35700     +167     
===========================================
+ Hits         17793    17979     +186     
+ Misses       17740    17721      -19     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

SUGGESTIONS BEFORE MERGE:

1. Build custom container here: https://github.com/skalenetwork/skaled/actions?query=workflow%3A%22Custom+Docker+and+Binary%22
2. Test it here: https://github.com/skalenetwork/skale-ci-integration_tests/actions?query=workflow%3A%22Skaled+Nightly+Tests%22
3. Edit VERSION file appropriately to your changes!
   See https://skalelabs.atlassian.net/wiki/spaces/SKALE/pages/2444951553/Branching+instructions

[dimalit]

I see 2 drawbacks of such approach:

1. UnDoS protection is coupled with the implementation (of logs/filter functionality). Architecturally more correct is to separate these two.
2. It unnecessarily introduces ("manual") parsing of filter/logs requests through rapidjson (and not through plain libjsonrpccpp as before. This can can introduce new possible bugs (in this new code).
   2a) As a side note I should mention that currently rapidjson-related part in SkaleServerOverride is implemented in a very "workaround" way and needs re-architecture. Growing it further with more calls would complicate things.

As a solution, I'd propose to implement this protection as an added layer in SkaleServerOverride class. It already has unddos protection - so this addition looks consistent. It can be implemented through something similar to mod_rewrite of Apache - i.e. scan request with simple regexp or plain c++ code and do appropriate filtering.