Use local memory pool inside update_rule_target_ex() to reduce memory footprint

[vkrivopalov]

Description

Previously, calls to msre_generate_target_string() from inside
update_rule_target_ex() would accumulate memory allocations from ruleset
memory pool that is never released. For reasonably large exclusion lists
memory consumption grows exponentially for no good reason.

This fix introduces the use of local memory pool for all intermediate
operations that is destroyed upon completion. This ensures that all
memory reallocations used for building strings are properly released.

Testing

Running Nginx with ModSecurity no user-defined exclusions:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     32371  0.0  0.2 220044 18408 ?        Ss   09:53   0:00 nginx: master process nginx
www-data 32372  0.6  0.6 542756 51520 ?        Sl   09:53   0:00 nginx: worker process

Running Nginx with ModSecurity in prevention mode, 40 user-defined exclusions of the following type:

SecRuleUpdateTargetById 10001-999999 "!ARGS:'/^param/',!ARGS_GET:'/^param/',!ARGS_POST:'/^param/'"

before the fix:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     32680  0.3 15.7 1477184 1264004 ?     Ss   09:56   0:00 nginx: master process nginx
www-data 32681  0.3 16.1 1799896 1297096 ?     Sl   09:56   0:00 nginx: worker process

Running Nginx with ModSecurity, 40 user-defined exclusions, after the fix:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1046  0.0  2.6 425760 212676 ?       Ss   09:58   0:00 nginx: master process nginx
www-data  1047  2.0  3.0 748472 245736 ?       Sl   09:58   0:00 nginx: worker process

Checked that configured exclusions apply, i.e., if an excluded parameter contains a malicious string the request is not blocked.

[marcstern]

Running in prod for many months