merge app and request contexts into a single context

[davidism]

Right now we have two separate contexts managed separately, the app and request contexts. This makes the implementation pretty complicated, as we need to maintain two context var stacks, and do a bunch of checks in the request context to make sure we're managing the correct app context. It makes an already confusing topic more complicated to explain: app context is active for requests and cli commands, don't push an app context before making a request, etc.

I think merging the two contexts could be possible. The single context (ExecutionContext?) would have the g, request, and session attributes, but accessing request or session when not in a request would raise an error.

[davidism]

I was never clear on why, but the contexts support being pushed multiple times. If the same context is pushed multiple times, the teardown functions are only run once it's fully popped. I don't think I've ever seen this used, and I can't think of a use case. There is a test, but it just demonstrates that the system works, it doesn't demonstrate any intended use of it. There's no docs about it. Perhaps it's a holdover from how things were tracked as a stack on top of thread locals, before things were refactored?

Having to keep track of a stack of how many times a context has been pushed complicates the implementation, especially when the request context also has to track whether it had to push an app context as well or if one was already present. It would be much easier (and probably faster and less memory) to error if the context is currently pushed.

This is not the same as being able to push different contexts on top of each other.