fix(sso): let LastaFlute own the SAML SLO redirect

[marevol]

Stacked on #3217 (which is stacked on #3214) — this PR targets saml-sp-url-settings. Merge #3214, then #3217, then this one.

1. The IdP-initiated logout response was written twice

getLogoutResponse() called the no-arg auth.processSLO(), which delegates to processSLO(false, null, false). When the incoming message is a SAMLRequest (IdP-initiated logout), java-saml builds the LogoutResponse and, with stay=false, sends it itself:

// ServletUtils#sendRedirect
if (!stay) {
    response.sendRedirect(targetUrl);   // commits the servlet response
}

Fess then threw SsoMessageException, and SsoAction#logout caught it, called saveInfo(...) and returned redirect(LoginAction.class) — a second redirect on an already committed response.

The call is now processSLO(false, null, true), so the URL comes back to Fess and the method returns HtmlResponse.fromRedirectPathAsIs(redirectUrl). LastaFlute stays in charge of the response. A SAMLResponse from the IdP produces no URL and still reports success through SsoMessageException, exactly as before.

2. NPE when SLO is not configured

Auth#getSLOResponseUrl() is

return settings.getIdpSingleLogoutServiceResponseUrl().toString();

and getIdpSingleLogoutServiceResponseUrl() returns null when neither the response URL nor the SLO URL is set. A LogoutRequest arriving in that state raised a NullPointerException, which the catch-all wrapped into a user-facing message built from e.getMessage() — literally the string null.

getLogoutResponse() now checks the URL up front and reports it, matching the guard logout(FessUserBean) already had.

3. Smaller items

• The trailing return null; was unreachable, because the mapped lambda always threw. The method now returns the mapped optional's value.
• SP metadata is served as application/samlmetadata+xml with a metadata.xml file name rather than application/xhtml+xml.

Test

test_getLogoutResponse_withoutIdpSingleLogoutServiceUrl covers the new guard. It is falsifiable: with the guard removed the request instead fails inside the Auth constructor with Invalid settings: idp_entityId_not_found, ..., and the test catches that difference.

Tests run: 130, Failures: 0, Errors: 0, Skipped: 0   (org.codelibs.fess.sso.**)

Not covered here

SP-initiated SLO still calls processSLO without a request ID, so the LogoutResponse is not bound to the LogoutRequest Fess sent — the equivalent of what #3214 fixes for the login flow. LogoutAction invalidates the session before the response comes back, so binding it needs a different place to keep the ID. Left for a follow-up.