feat: [OCISDEV-531] add the vault capabilities endpoint support

[2403905]

When CapabilitiesVault.Enabled is true, GET /ocs/v2.php/cloud/capabilities?vault=true returns a modified response with public sharing and federation sharing disabled.

[jvillafanez]

Would it be better if we consider some kind of space-type capabilities? Something like "spaces.personal.sharing.public.enabled = true" and "spaces.vault.sharing.public.enabled = false". If vault isn't enabled in the server, there won't be a "space.vault" key, so the client can use that to detect whether the vault is enabled or not.

We'd need to plan to migrate to the "space.personal", but we could also use the current capabilities as a fallback

There are a couple of advantages:

• Clients can access to the new capabilities without big changes. The endpoint is the same and it will contain everything available.
• Those keys can be extended if needed. In theory, we could include capabilities per space. The space with id "abc-123" (if we decide to identify the spaces by id) could have its own capabilities.
  • If this could be a thing, we might consider using "spaces.personal.personal.sharing.public..." instead since we probably would want the "spaces.personal.*" spaces to inherit the capabilities from the "spaces.personal.personal" one.
• If we don't want to expose vault capabilities to "not-authorized-enough" users, we could also check for 2FA before populating the vault information.

[LukasHirt]

Would it be better if we consider some kind of space-type capabilities?

This feels to me like it could grow cumbersome pretty quickly in case we introduce non-space vault related capability. Example: we are now providing different themes for vault and even though we just handle it in the frontend now, we might handle this in the future in capabilities as well which would then mean having:

• space.xxx
• space.vault.xxx
• themes.xxx
• themes.vault.xxx

And if something else comes it just keeps growing.

Clients can access to the new capabilities without big changes. The endpoint is the same and it will contain everything available.

I would consider adding the extra param into the endpoint actually easier change compared to now accessing space capabilities with a new nested key. Also, this would be backwards compatible. If we'd change how we access existing capabilities, running clients with older versions would break.