In these cases the `return` might end up creating a new HTTP response, so they
need to be modeled as such.
Initially I created a very naive solution that didn't handle either
tricky_return1 or tricky_return2.
The interaction in tricky_return2/helper highlighted for me that to handle this
properly, due to the fact that the flow is across functions, we either need to
use a global dataflow/taint-tracking configuration, or some clever use of
type-trackers.
In the end, this extra effort for not modeling all returns in a flask route
handler as a creation of a HTTP response doesn't really seem to be worth it (at
least not right now). Sicne we use it with taint-tracking for the Reflected XSS
query, and use a HTTP response _creation_ as the sink (without propagating taint
to the HTTP response), we won't get into trouble where we report a path to BOTH
`make_response(...)` and the `return`
```
resp = make_response(...)
return resp
```
If we change this setup in the future, we will probably need to do something to
avoid this double-path reporting.
When dealing with
```
resp = make_response(...)
return resp
```
ideally we don't want to mark the return as a creation of a HTTP response. I'll
deal with this in a second commit, to show off how annoying it looks in the
tests right now :D
I'm not even trying to model it properly right now, and don't have a specific
use-case for it RIGHT NOW. I think we could want this in the future, but I think
it's probably better to model it when we know what we want to use it for.
We might need to rework this a bit when we also start to handle redirects. I
could see a world where we simply allow http redirects to be subclasses of http
responses, and need to manually exclude them from queries (or create
HttpContentResponse to model the HttpResponses that will contain a body). Let us
see where the wind will take us.
I looked through JS and Go libraries, but I didn't feel their modeling would map
very well to Python.
Added it to the `testapp` so it's easy to run the server to SEE that it works.
Added it to `routing_test` so it's obvious this is supported by our modeling
when we _know_ it's running Django 2/3.
