OF-3188 + OF-3189: Add generic support for XEP-0128: Service Discovery Extensions

[Fishbowler]

I want to implement XEP-0504: Data Policy (https://xmpp.org/extensions/xep-0504.html) which relies on XEP-0128: Service Discovery Extensions.

We've already got 2 specific XEP implementations (Contact Addresses, Software Info) that depend on XEP-0128, and we've got the MUC Extended Info plugin that extends disco responses too.

This change creates a pluggable ExtendedDiscoInfoProviders capability for plugins to add support for XEPs (or other functionality) that rely on XEP-0128.

It also moves the Contact Addresses and the Software Info implementations to use the new thing, and updates the DOAP.

Lots of AI in the JavaDoc and unit tests, which I think I've fixed up, but use sufficient scepticism.

[guusdk]

I've left some minor feedback inline. There's an overarching concern: conceptually, this change feels odd to me. It doesn’t introduce new functionality, but rather an alternative way to achieve the same result. Openfire already provides an extension point for obtaining “extended infos” via org.jivesoftware.openfire.disco.DiscoInfoProvider#getExtendedInfos. This commit introduces a second mechanism for essentially the same purpose. In fact, the getExtendedInfos method in the new ExtendedDiscoInfoProvider has the exact same signature as the existing one, which feels like a code smell.

The main difference seems to be how the data from DiscoInfoProvider and ExtendedDiscoInfoProvider is combined into the final result, with the new provider adding more complex merging logic. I wonder whether this PR could be improved by eliminating the second provider and instead applying the merging logic to the existing extension point. Is there any functionality enabled by the current approach that wouldn’t be possible that way?

[Fishbowler]

@guusdk

this change feels odd to me. It doesn’t introduce new functionality, but rather an alternative way to achieve the same result. Openfire already provides an extension point for obtaining “extended infos”

The existing functionality doesn't expose an ability to extend disco results via a plugin, except via the proxy approach in mucextinfo.

This felt like a good way to offer a simple hook to plugins. There's a much simpler version that deals with stuff like Data Policy, but I also wanted to cater for mucextinfo and similar, and bring the merge stuff in-house at the same time.

Right now, the testing has shown that this implementation has gaps (like not covering MultiUserChatServiceImpl or PubSubModule's implementations of getExtendedInfos), so if you've got thoughts on how to better encapsulate this functionality for a plugin to extend a disco#info, am happy to adapt.

I'm thinking that I might pull some stuff out of the anonymous DiscoInfoProvider at L616 and put it into the IQDiscoInfoHandler and call it from handleIQ instead (where it calls out to the other implementations). But at the point where its being hoisted to the root of the class, it could also all be moved to some sensible place in a file nearby, probably as mostly static methods... WDYT?

[guusdk]

The name of this is somewhat ambiguous to me. Am I also seeing distinct ENABLE properties for each specific provider that adds a detail? Do we need two settings that partially overlap? On first thought, I'd prefer to remove this particular one (as it's not very clear to what it does or does not apply).

[Fishbowler]

I thought the description in the i18n was pretty good? Its purpose seems more concrete in the old impl here where it's fetch wraps a bunch of extra stuff that would get added to the disco info if this "privacy mode" isn't enabled.

[Fishbowler]

Presently, this is just tidying what was there before to fit The New Thing, intentionally not altering logic or behaviour of these properties or of the Contact Addresses / Software Info implementation. Happy to, though, if you think it's warranted.