EPIC: Rewrite the MVC Dispatcher

[albe]

With the introduction of the PSR-15 middlewares (#1928 and #2019) we cover the whole HTTP dispatch process in a standard and extendable way. At the inner core of this middleware process is currently the MVC dispatcher, which is responsible to convert an Http request to an ActionRequest, resolving a Controller, dispatching the ActionRequest to that Controller and receiving or wrapping the action return value in an ActionResponse, which is then converted into an Http Response that is further piped through the PSR-15 middlewares.

The ActionRequest and ActionResponse abstractions give a nice high level abstraction of the underlying http messages, but currently it's not possible to interact with those in a cross-cutting concern other than inside the controller. Also, the MVC dispatcher currently holds a couple of responsibilities (resolving controller, looping the dispatch attempts, handling authentication errors, etc.). Therefore it might be benefitial to split the dispatcher into another middleware layer that acts upon an ActionRequest and an ActionResponse.

Related / Todos:

• Move content-type negotiation out of the Controller into an HTTP middleware #1305
• Maybe? Add support for basic localization through routing and request parameters #1233
• FEATURE: Tooling for working with response headers in controller #3291
• Move firewall out as middleware
• !!! FEATURE: WIP Dispatcher and controller return ActionResponse (simpler controller pattern) #3232

[albe]

/cc @sorenmalling

[sorenmalling]

The firewall is also handled inside the Dispatcher. This could be moved out as a middleware in such a iteration

[sorenmalling]

Assigned @albe and myself to hold os accountable on the other side of the Flow 7.0 release :)

[albe]

One idea: Let's move the currently deprecated Http\Headers class into the Mvc namespace and make it part of the ActionResponse API in order to specify headers to set in the response, instead of the SetHeaderComponent parameter currently.
The idea is that ActionResponse is a higher level abstraction of a response and Headers is a (slightly) higher level abstraction of basic Http headers that hides some details like the Cache-Control stuff. Also we need a replacement for the SetHeaderComponent and just moving that to a middleware that still needs to fetch the specified headers from some global context feels weird. With the Headers inside the ActionResponse, the MVC Dispatcher can translate the ActionResponse into a HTTP Response with headers, which is more straightforward.

We could even do this right now already.

[albe]

Related #2219 resp. aeb132d - reverting this commit could be a basis for re-adding the Headers class into the ActionResponse

[mhsdesign]

Ill move the Headers related discussion over here: #3291
Thanks for all the crumbles you left me. Today i was quite the detective :D