Full SOAP logout impl committed.

A small change was needed to make the outgoing bindings a dynamic setting so that the propagation flow knows whether to do SOAP only or all of the bindings, and this impacted a lot of other flows, and some of the Spring machinery that maps bindings to MessageEncoders but I think I hit all the places using it, including CAS.

More testing in progress but with a lot of small redesign work and some slightly ugly workarounds, the back channel SLO flow is close to working with propagation handled by actually running the existing SAML 2 subflow. CAS will need more study as I think it does things differently.

The "outer" SOAP exchange is interrupted to iterate over each SPSession by saving off a bunch of contexts and restoring them afterwards. Ugly but it seems to be working.

We only track one SPSession per SP, so in practice this is mostly ok and doesn't duplicate SOAP messages to the same SP.

Biggest redesign needed was to adjust the outbound binding handling in all the flows to use a lookup strategy so the propagation flow can dynamically adjust the outbound bindings to SOAP-only on the back-channel.

Big commit should come later this week.

Back channel propagation during front channel is working with the out of the box SOAP client using the testbed to mock responses. Need to test more error conditions and get additional cleanup done before committing.

True back channel is nominally "easier" in a sense but will take some more work to reuse the primary SOAP logout action, probably a lot of ugly lookup strategy wiring to divert the lookup of the various contexts but the main hurdles are dealt with.

answer of microsoft: ADFS doesn't support SOAP logout propagation in their current version (ADFS on Windows Server 2016)
I'm still interested in the implementation in Shibboleth. Thanks, Arjan.

Getting some findings down as I swap some of this back in...

Current logout propagation flow for SAML 2 avoided the SOAP gap by only enumerating the front-channel bindings as outbound options when it does the endpoint lookup, so SOAP is just skipped.

The flow itself is designed around the front-channel assumption because it assumes it should end by encoding the LogoutRequest it creates as the client response, which won't work for SOAP.

We'll need to fork that flow to handle the SOAP case separately, not sure how/where yet. Maybe we resolve the outbound binding/endpoint, and if it's SOAP, we branch off there instead of actually encoding the message.

The branch will have to invoke the SOAP client against the LogoutRequest, get back the result, and then render the saml2-result view. Right now that view gets rendered by the main SAML 2 SLO flow, which branches on a LogoutResponse. We should be able to patch that up by feeding that view a context variable containing the LogoutResponse. In the current front-channel case, that's the inbound message, but with SOAP it will come from the response back from the SOAP client request. The result view is a system template so we can adjust it without breaking existing installs.