memory leak fixes and optimizations

[tarunKoyalwar]

Proposed changes

• Implement Response Chain
  • doesn't re-allocate when memory when following redirect chain instead reuses them
  • global http response buffers reuse
• adds -jsc flag javascript concurrency with 120 default (i.e in parallel 120 flow executors and 120 javascript protocols exec can occur)
• refactor javascript vm/compiler logic + remove unused code
• overall improvements to memory and cpu usage
• follow up issue for extended memory usage optimizations Extended Memory Usage Optimizations #4703

Observations

• From testing it was observed that running nuclei on 1k targets with default concurrency settings runs without crash and requires 2vcpu and 3GB(depends on http response of target, but 3GB is good maximum to have)

Checklist

• Pull request is created against the dev branch
• All checks passed (lint, unit/integration/regression tests etc.) with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

[Mzack9999]

suggesting minor spelling changes + question on failing tests

[tarunKoyalwar]

TODO

• above changes (related to js) were experimental but idea seems to have worked. need to do following before fix is ready
  • fix failing integration test (caused by http response chain)
  • remove dead code ( we don't use capture variables - not supported in templates)
  • finalize implementations
  • do some scans probably 5k targets + javascript templates to identify appropriate js concurrency from practical testing
  • add -jc -js-concurrency to control/limit max js vms or (in limit total inuse vm's) . this flag govern's both flow executor js and javascript protocol js vm

[rxerium]

Hey team, I'm still experiencing memory issues unfortunately (on version 3.1.10). I'm reverting to version 2.9.15 to resolve the issue and also note I'm running scans through docker.