Python: Port Flask models to use API graphs

[tausbn]

Most of the type trackers in this model were easily replaceable with
uses of the API graph, but the ones for tracking subclasses are
problematic, as these take us out of the API graph.

---

This is still a WIP, but in the spirit of ship-to-learn I'm putting it up now. It's already much more succinct than the original. 🎉

To handle subclasses, I will look at extending the API graph to account for these by adding edges and nodes where appropriate.

To do:

• Performance testing.

[yoff]

This is fantastic! I also like how the intermediate results are kept as API::Nodes.

[yoff]

This certainly looks a fair bit more polished :-)

[RasmusWL]

Nice 👍

I like that we now allow dotted names as imports, since it makes things feel a bit more natural.

CallCfgNode

I'm also a fan of CallCfgNode (although the name does kinda stick out). I'm wondering if making this change would result in the same behavior?

 private class FlaskAppRouteCall extends FlaskRouteSetup, DataFlow::CallCfgNode {
   FlaskAppRouteCall() {
-    this.getFunction() = flask::Flask::route().getAUse()
+    this = flask::Flask::route().getACall()
   }

Future of modeling

Now that things are so easy to model, we can reconsider how we want our modeling to look like. With type-tracking there was a need to expose every little bit we were interested in, but we don't need that anymore.

I don't think we need to do that in this PR per say. I have a few ideas, so I'm happy to merge this PR (once we've verified no performance problems), and create a draft we can discuss.

The two major things I think we can do now are

1. Remove explicit modeling of things that are only used once.

   For example, changing our modeling to be the following, we can remove the route predicate entirely from the flask::Flask class

   -FlaskAppRouteCall() { this.getFunction() = flask::Flask::route().getAUse() }
   +FlaskAppRouteCall() { this.getFunction() = flask::Flask::instance().getMember("route").getAUse() }

2. Restructure class/predicate layout. Since we don't need explicit CodeQL modules for all Python modules we care about anymore, we can restructure things a bit, and expose the things we care about in a manner that (potentially) makes more sense from a modeling perspective.

   For example, we could remove the flask:: prefix on everything.

[RasmusWL]

I was just about to merge this PR, but then remembered that we still need to do performance testing... so I converted it to a draft so we don't accidentally merge it 😄

[tausbn]

1. Remove explicit modeling of things that are only used once.
   For example, changing our modeling to be the following, we can remove the route predicate entirely from the flask::Flask class

-FlaskAppRouteCall() { this.getFunction() = flask::Flask::route().getAUse() }
+FlaskAppRouteCall() { this.getFunction() = flask::Flask::instance().getMember("route").getAUse() }

2. Restructure class/predicate layout. Since we don't need explicit CodeQL modules for all Python modules we care about anymore, we can restructure things a bit, and expose the things we care about in a manner that (potentially) makes more sense from a modeling perspective.
   For example, we could remove the flask:: prefix on everything.

I think these are excellent suggestions, but probably best left for another PR (as the commit history for this one is getting a bit complicated). I'm in favour of doing both of the things you suggest.

[tausbn]

Performance seems decent, and will be possible to improve once we've moved all of our type trackers to API graphs. This can now be merged as far as I'm concerned.

[RasmusWL]

Alright, let's go 🚀