Set target_frontend after handling the disco response
Set target_frontend after handling the disco response

When the processing of the request micro-services is finished, the
context is switched from the frontend to the backend. At that point
target_frontend is needed to set the state of the router. The router
state will be used when the processing of the response by the response
micro-services is finished, to find the appropriate frontend instance.

---

The routing state is set at the point when the switch from the frontend
(and request micro-service processing) is made towards the backend. If
the discovery response was not intercepted by the DiscoToTargetIssuer
micro-service, and instead was processed by the backend's disco-response
handler, the target_frontend would not be needed, as the routing state
would have already been set.

When the DiscoToTargetIssuer micro-service intercepts the response, the
point when the switch from the frontend to the backend happens will be
executed again. Due to leaving the proxy, going to the discovery service
and coming back to the proxy, context.target_frontend has been lost.
Only the state stored within context.state persists (through the
cookie).

---

When the request micro-services finish processing the request,
backend_routing is called, which sets the router state
(context.state['ROUTER']) to target_frontend, and returns the
appropriate backend instance based on target_backend. When the time
comes to switch from the backend to the frontend, that state is looked
up (see below).

When the response micro-services finish processing the response,
frontend_routing is called, which sets target_frontend from the router
state (context.state['ROUTER']) and returns the appropriate frontend
instance based on target_frontend.

---

Signed-off-by: Ivan Kanakarakis <f60d6943d72436645c4304926eeeac2718a1142c@gmail.com>

its-dirg/SATOSA,SUNET/SATOSA,SUNET/SATOSA