fix: TX variables may be overwritten

[azurit]

Fixes #5.

[azurit]

@airween Can you pls test this? Not sure if this solution is going to work. Ignore failed tests, it is currently broken for this repo. Thanks.

[airween]

Two notes:

• I tried this and got this error: "modsecurity_rules_file" directive Rules error. File: /path/to/coreruleset/plugins/referer-hardening-config.conf. Line: 54. Column: 15. syntax error, unexpected ","
• I'm not sure this will solve the problem, because this is in the plugin's config file. As I wrote in Probleme with #9524190 / TX:referer-hardening-plugin_por #5 the problem appears because a regular CRS rule fills the TX slots during the transaction. Config files' rules are evaluated before those rules. So now you reset the slots, but the mentioned rule will fill them again.

[azurit]

@airween

* I tried this and got this error: `"modsecurity_rules_file" directive Rules error. File: /path/to/coreruleset/plugins/referer-hardening-config.conf. Line: 54. Column: 15. syntax error, unexpected ","`

I don't see any problem there. It works for me. Also, the error from tests is this:

Error: failed to find start marker: ftw/run: can't connect to destination &{DestAddr:127.0.0.1 Port:80 Protocol:http}: dial tcp 127.0.0.1:80: connect: connection refused

Which doesn't looks like a syntax problem.

* I'm not sure this will solve the problem, because this is in the plugin's `config` file. As I wrote in [Probleme with #9524190 / TX:referer-hardening-plugin_por #5](https://github.com/coreruleset/referer-hardening-plugin/issues/5) the problem appears because a regular CRS rule fills the `TX` slots **during the transaction**. Config files' rules are evaluated **before** those rules. So now you reset the slots, but the mentioned rule will fill them again.

You are right. Maybe the best would be to move rule 9524140 to phase 1 so it runs before CRS.