Ruby: Improvements to RegExpTracking

[hvitved]

When #11879 switched from using global data flow to using type tracking, for identifying regular expressions, we lost flow through built-in string methods. This is because the conjunct

TaintTracking::localTaintStep(nodeFrom, nodeTo) and
nodeFrom.(DataFlowPrivate::SummaryNode).getSummarizedCallable() instanceof String::SummarizedCallable

doesn't work in type tracking, where we don't have flow-through. Instead, we should be using FlowSummaryImpl::Private::Steps::summaryThroughStepTaint, which this PR does.

Moreover, this PR improves on performance by strengthening the initial forwards/backwards pruning, which also revealed a bug in the existing TypeBackTracker::getACompatibleTypeTracker predicate.

DCA shows a nice speedup on artichoke__artichoke.

[erik-krogh]

Your implementation looks good.
I'm used to "content" just being string-constants that directly correspond to property names, but I see that it's actually more complicated here.

You are using that string-constants gets converted to regular-expressions, but not the other way around, which makes the implementation conceptually simpler.
I should probably have done that from the start.

---

As said, the implementation is fine, but I don't think the readability is.
E.g. what is n in regFromString?
I know what the code did previously, which helped in reading it.
But I think the rest of the Ruby/Python team will find it harder.
If you can look through the code again and give some more descriptive names (and maybe some selective docstrings), that would help.

[erik-krogh]

LGTM 👍

But I think you also need a review from the language teams.
@github/codeql-python / @github/codeql-ruby: your turn.

[yoff]

The Python change is good, thanks :-)
As I now read the other parts also, I left some questions, but they are mostly for my own curiosity..

[yoff]

LGTM - nice refactor, I enjoyed reading that :-)