In PR #13823, we had rewritten the endpoints that are being considered for framework mode. We used to use `DataFlow::ParameterNode` as endpoints.
However, `ParameterNode`s do not exist for the implicit `this` parameter; they also do not exist for bodiless interface-methods.
In PR #13823, we forgot to model that `this` only exists for non-static methods and to only consider parameters that we have source code for.
Reverts the change made in
daf2743143
With the change in the aforementioned commit, we were extracting candidates for endpoints that
had a neutral _summary_ model. These are bad candidates, as they have already been triaged.
Uses the same trick as for the negative examples, this time with a limit of 7
candidates for each endpoint signature.
As this duplicates some of the logic used in another query, it may be worthwhile
to consider extracting this into a shared parameterized module.
Exposes the same information as the existing queries through two query
predicates instead. This makes the downstream data gathering a bit more
convenient to implement.
While the string representation is useful for quickly modifying queries, it's
a bit clunky when the data needs to be further parsed. Instead, the two queries
now select all of the columns of the sinkmodel separately (which makes it easy
to pull them out of the relevant output later on).
This fixes the name of reported external APIs for nested types.
The `toString()` method of `getSourceDeclaration()` would report the
name of a type, but not the name of the enclosing type. This results
in missing information in the `UnsupportedExternalAPIs.ql` query.
For example, previously it would report:
```
org.zapodot.junit.db.Builder#build()
```
However, the `Builder` class does not exist in the package and is only
a nested type within `EmbeddedDatabaseRule`. The correct name should be:
```
org.zapodot.junit.db.EmbeddedDatabaseRule$Builder#build()
```
This name also matches the format of MaD.
