Fix Rejection branching in warp filters (#1177)

[tyranron]

Resolves #1177

Synopsis

See #1177:

Describe the bug
with juniper_warp = "0.7.0", this sequence can happen:

1. request comes in with valid application/json body.
2. post_json_filter runs; context_extractor fails for some transient reason (database error in my case), returns some Rejection that should produce a 5xx error.
3. then post_graphql_filter runs. context_extractor happens to succeed this time. post_graphql_filter returns a 4xx rejection about a parse error because the body's actually in json format.

Solution

Seems like seanmonstar/warp#487 (comment) hits the exact issue we have here:

The problem is that or() currently swallows the error

or() is designed to swallow the error. If you need access to the error, use or_else()

So, we should replace or() filters branching with or_else() one.

See #1177 (comment):

• Rework make_graphql_filter to execute context_extractor only once.
• Provide a usage example with fallible context_extractor and mention rejection issue in API docs.
• Re-check whether query, body and json filters used inside make_graphql_filter require recover()ing handle into hard errors.

Checklist

• CHANGELOG entry is added
• Covered with tests
• Documentation is updated