Fix:Polynomial-time regular expressions

[marcotc]

This PR fixes two cases where there was a possibility of polynomial-time being required to process regular expressions in ddtrace.

These regular expressions have been modified but still match their desired input.

The main changes were:

• Use Possessive Quantifiers (*+ in this case): this means that * will not allow backtracing after it has matched a character, even if this means that the complete regex match will fail.
• Reduce the character matching set from "anything" (.) to "not ]" ([^\]]) when matching IPv6 addresses. This is import because the next character match in the regular expression is ], which means . might try to match it but not [^\]].

[delner]

Looks fine. Where are the unit tests for these functions? Just want to make sure we're already covering their expected inputs/outputs (such that we're not breaking behavior.)

Secondarily, does it make sense to put any benchmarks/perf tests around these as well? To ensure additional alterations in the future would make regressions in performance visible.

[marcotc]

Looks fine. Where are the unit tests for these functions? Just want to make sure we're already covering their expected inputs/outputs (such that we're not breaking behavior.)

I double checked, and yes, these 2 cases are appropriately covered by unit testing.

Secondarily, does it make sense to put any benchmarks/perf tests around these as well? To ensure additional alterations in the future would make regressions in performance visible.

Any regular expression can be pathological if it includes a polynomial-time pattern.
So, technically, all regexs would have to undergo performance testing.
Because it's possible know if a regular expression takes polynomial-time to process by analyzing the pattern itself, we use CodeQL to protect us.
CodeQL recently introduced polynomial-time regular expression protection for Ruby, thus the reason these regular expressions have existed in our code base, despite CodeQL being enabled for a while.

From now on, it should not be possible to commit polynomial-time regular expressions without CodeQL catching it.