Allow disabling the logout on provider side

Thanks for looking at it, and you are right — my report was imprecise on that point.

I did not deduce NONE from the code. The field is free text: OIDCClientConfigurationClassDocumentInitializer line 96 does

xclass.addTextField(OIDCClientConfiguration.FIELD_LOGOUT_MECHANISM, "Logout mechanism", 255);
so any string can be entered, and there is no enum, no list of allowed values and no default. NONE was our own assumption while trying to stop XWiki from ending the session at the provider — it simply looked like the most plausible value for "no mechanism". That should have been stated in the report.

The observation itself does not depend on the value, though: nothing acts on it. Searching the whole repository on master (all 118 Java files and all 58 non-Java files) gives 8 occurrences in 3 files:

OIDCClientConfigurationClassDocumentInitializer line 96 — creates the text field
auth/store/OIDCClientConfiguration lines 276, 1010, 1014, 1017, 1019 — constant, getter, setter
auth/internal/OIDCClientConfiguration lines 398 and 1925 — the property name oidc.logoutMechanism and its case in the getter dispatch
PROP_LOGOUT_MECHANISM appears only at its definition and in that case, so no caller ever queries the property. Nothing outside the Java sources mentions it either — no xwiki.properties template, no class definition, no documentation file in the repository. That matches your reading that it was never really a thing.

So what remains from my side is narrower than my original title: the field is created in the configuration class and can therefore be set on the configuration object, while no value has any effect. Removing the field, its getter and setter would be fine for us.

On the feature you renamed the ticket to, I do not want to overstate our need. Our actual problem was a logout that immediately logged the user back in silently, and that is solved by pointing logoutEndpoint at a local URL. Disabling the logout on the provider side is not something we need — for shared devices we would rather have the opposite.