feat: Fixing FP on plugins page

[azurit]

Plugin descriptions contains lots of data (like changelogs, error messages and so on) that triggers our response body rules.

[EsadCetiner]

@azurit LGTM, but do you have any example payloads that you can add to the tests file?

[azurit]

@EsadCetiner I have an example data but not sure if it's suitable for a test for rule 953100 as it contains PHP error message (which is supposed to be blocked). It was part of the chanelog:

Fixed: Call to a member function get_meta() on null error on WooCommerce order received page (thanks [Dekadinious](https://github.com/Dekadinious))

Also, i'm not sure about rule 951240 which triggers on CRS 3 but does NOT trigger on CRS 4. Example data:

warnings</p>\x0a<p>=1.9=<br />\x0a* [Added] Donation link because I&#8217;m poor<br />\x0a* [Removed] errors and deprecating warnings</p>\x0a<p>=1.8.1=<br />\x0a* [Updated] Renamed function from ‚my_profile_update‘ to ‚apg_profile_update‘

I would include it in the exclusion rule with a comment that it is not a case anymore on CRS 4 and can be removed after we drop support for CRS 3. What do you think?

[EsadCetiner]

@azurit I don't see a reason why you shouldn't, it's legitimete data that's being wrongfully blocked. I'd add a test for 951240 as well even if the false positive doesn't exist with CRSv4. @theseion and I have been thinking of rewriting false positive tests for rule exclusion plugins to check if no rules are being triggered against a set of payloads known to cause false positives. The idea came from reviewing a PR but I haven't explored the idea just yet.