JavaScript: Replace all uses of tracked nodes with type tracking.

[xiemaisi]

This has turned into a fairly big PR, with three layers of commits (which I'd be happy to submit as separate PRs if desired):

• The first group of commits replaces all current uses of tracked nodes (in the socket.io and HTTP libraries) with type tracking.
• The second group of commits tweaks caching structure and refactors a few predicates to avoid unhelpful magic exposed by the first group of commits. These are intended to be behaviour-preserving.
• The third group of commits extends type tracking with support for tracking through one level of properties, since otherwise we're losing results compared to tracked nodes. This entails a small change to the API, see the qldoc of TypeTracker and TypeBackTracker for details.

Performance is pretty awesome (internal link). The new results on NodeGoat look like (seeded) true positives; the regexp injection on semmle-express-test is, I think, a false positive that is unrelated to this PR (we assume every call to match with the right arity does regexp matching); and the remote-property injection results are harmless (the object into which the properties are injected has a null prototype).

[asger-semmle]

LGTM overall

I was a bit sad to a see the style is different from the one I've been using and tried to advocate in a few places. Of course, that was just a style I made up and we haven't agreed upon as a team, but I think it's worth picking a one style and sticking with it. The differences between the two styles are currently:

• What I have called t2 is here called s, prev, or next.
• What I have called ref is here called flowsToSourceNode.
• What I phrased as "with t summarising the data flow path" (although usually omitted) is here phrased as "with type tracking info stored in t".

Apart from the flowsToSourceNode change I wouldn't mind adopting the same style. If you're happy with these choices, could you update the qldoc and test cases in library-tests/TypeTracking to reflect this?

About caching: my intention was the StepSummary::{step, append, prepend} would be cached, and track and backtrack would be pragma[inline]. It was reassuring to see you arrived at something similar, although I think we can still get more by caching step. We'd need to find a way to cache both step and a reordered copy of step for use in backtrack, though that's something we can investigate later.

[asger-semmle]

Could you confirm that the import graph is unchanged?

[xiemaisi]

Oh, good idea. It'll require rebuilding some snapshots, but seems worth doing.

[xiemaisi]

Apart from the flowsToSourceNode change I wouldn't mind adopting the same style

Yeah, flowsToSourceNode is horrible; I'll change to ref.

I found myself preferring prev and next over t2 because it clarified in my mind which direction the tracking was happening in, and indeed I made a few mistakes that I caught that way. s is no good, though, I'll get rid of it.

I don't think there was any good reason for me changing the description of t, so I'll just revert to what you had earlier.

[xiemaisi]

Naming suggestions addressed; running the import graph comparison now.

[asger-semmle]

Thanks for the update. Let's wait for the import graph check, but otherwise LGTM now.

[xiemaisi]

No changes to PathExpr::resolve on our default projects. Is there anything else you'd like me to check?

[asger-semmle]

Good enough for me