Regex key non-matches with libModSecurity persistent storage

In ModSecurity v3, when using persistent storage of variables (i.e. lasting beyond a single transaction -- either with the in-memory option or the lmdb option), some regular expression matches for variable keys may not match as would reasonably be expected.

E.g. Consider this set of rules:

SecAction "initcol:ip='127.0.0.1',id:6000,pass,phase:1"
SecRule ARGS "@rx ." "id:6101,phase:2,pass,setvar:ip.mycount1=1"
SecRule IP:'/mycount1/' "@rx ." "id:6102,phase:2,pass,log,msg:'matched is %{MATCHED_VAR}'"
SecRule IP:'/^mycount1/' "@rx ." "id:6103,phase:2,pass,log,msg:'matched is %{MATCHED_VAR}'"

And then execute: curl http://localhost/testget.php?a=b

Rule 6101 has created the variable 'mycount1' within the IP collection for 127.0.0.1. Its value can be accessed using the variable-key regex specification in rule 6102.

Rule 6103, however, will not match the variable key. In this case the regex pattern passed to pcre is 127.0.0.1::::^mycount1. This obviously will not yield the result one would ordinarily expect from looking at rule 6103.

This behaviour was not seen in ModSecurity v2.

Start by reproducing the issue with the four SecAction/SecRule examples and the curl request, then trace the persistent-storage variable-key regex handling in the C++ code. Compare the in-memory and lmdb behavior with the shown rules; done means the anchored ^mycount1 pattern matches the stored key as expected, without breaking the existing regex case.