Data flow: Cache TNodeEx

[hvitved]

This PR moves the TNodeEx newtype from DataFlowImpl.qll into DataFlowImplCommon.qll (and makes it cached). The purpose of doing this is to avoid an additional newtype creation for all instantiations of the data flow library, and as witnessed by the DCA runs it has a very positive impact on memory/cache usage (and in general also a modest impact on timing).

Before moving the newtype, the first commit removes the Boolean hasRead column from TNodeImplicitRead, in order to the size of the newtype when later caching it. This commit then also adjusts the generated edges relation by never revealing the implicit reads that happen at sinks.

Commit-by-commit review is suggested.

[geoffw0]

CPP, Swift changes LGTM. DCA looks fine as well, though performance-wise I can only detect wobble.

We've lost some duplicate nodes in Swift, which is probably a good thing assuming it was expected.

[aschackmull]

Two comments so far:

• I don't think it's necessary to cut down the size of NodeExImpl based on the configuration - simply restricting the read step relation instead ought to achieve the same and we avoid both scanning the NodeExImpl relation to create the reduced type and the risk of the compiler inserting hard-to-eliminate type-checks.
• There's a bug in relation to provenance: When we merge the last two steps before a sink where the final step is an implicit read, and both steps have non-empty provenance, then we lose the sink-provenance.

[hvitved]

@aschackmull : PR ready for review again.

[aschackmull]

Is this a relevant addition? Isn't this just for identifying subpath-wrappers through hidden callables?

[hvitved]

It matters when you have a subpath that ends at a sink, for example https://github.com/github/codeql/pull/17300/files#diff-54bce82118abe557abb0786a2be4a5761bd9ba673e50323071469138c6d57a56R597.

[aschackmull]

That anchored link doesn't work for me. But it makes sense 👍

[aschackmull]

One minor comment, otherwise LGTM now.