direct_response precedence over CORS pre-flight response

When using `direct_response`, it _seems_ to take effect with higher precedence than the `envoy.cors` filter, even if `envoy.cors` is first in the `http_filters` list.

My http config is essentially:
```
http_filters:
- name: envoy.cors
- name: envoy.filters.http.jwt_authn
config: { ... }
- name: envoy.router
route_config:
virtual_hosts:
- cors: { ... }
...
routes:
- match: { path: "/ping" }
direct_response: { status: 200 }
```

If I change `direct_response` to a `route` to a dummy cluster, a pre-flight OPTIONS request returns the right cors response, but with `direct_response` the response is the vanilla 200 even for the pre-flight request. It's possible to use a header method match to manually construct a different response for OPTIONS vs other requests to that route, but ideally there would be a way to configure a route action to be a direct response that acts on the request after cors (and other filters) have done their work.

The use case here is e.g. a `/ping` endpoint that goes through the filter stack and sends a direct response after validating the JWT etc.