[Proposal] Inform user about master key generation on encryption enabling

[func0der]

• Resolves: kinda discussions in Missing "Enable recovery key" field in the admin settings #8283 but also a lot of weirdness and questionmarks around this topic.

Summary

The user/admin should be informed about the fact that the encryption is generating a master key for the whole instance.
This default behavior was introduced in Nextcloud 13 and was not properly communicated (as it seems). There was no trace to be found in the docs, nor was there anything in the interface warning the non-RTFM users about this.

This change to a less secure, but more user friendly setup, should be clearly communicated to the user since Nextcloud is used in more and more setups which require them to be compliant with very high privacy standards.
If the user is not pro-actively informed about this setup, they might violate those standards by accident.

TODO

• Add language file entries for all languages (done when this change finds acceptance)

Checklist

• Code is properly formatted

• Sign-off message is added to all commits

• Tests (unit, integration, api and/or acceptance) are included

• Screenshots before/after for front-end changes
  
  

• Documentation (manuals or wiki) has been updated or is not required -> Clarify the use of a master key during setup of encryption documentation#11122

• Backports requested where applicable (ex: critical bugfixes)

[joshtrichards]

Hi @func0der - Thanks for working on this and giving some thought to the user experience side! I also saw your directly related PR for the docs (nextcloud/documentation#11122).

There are a handful of outstanding/overlapping server-side encryption Issues/PRs in the docs section right now, some of which directly touch this matter (https://github.com/nextcloud/documentation/labels/feature%3A%20encryption%20%28server-side%29)

Here's what I suggest:

• Let's see if we can use your recent PR in the docs repo to finally clean up the server-side encryption documentation a bit (in this particular area at least)
• Once the docs are clear(er), let's see bring some of it's language into this PR and/or reference it

I'll also try to consolidate some of the duplicate Issues in the docs repo that cover this topic.

[func0der]

Anything that clears this matter up is a welcome change :D

[susnux]

Suggested change

	<li>{{ t('settings', 'By default a master key for the whole instance will be generated. Please check if that level of access is compliant with your needs.') }}</li>
	<li>{{ t('settings', 'By default a master key for the whole instance will be generated. Please check if that level of access is compliant with your needs. If needed refer to the documentation on how to enable per-user keys.') }}</li>

[szaimen]

Sounds good to add this

[szaimen]

Hm... wouldnt this conflict with #50424?

[susnux]

@szaimen yes but that information is still there and we should add that part

[susnux]

@func0der took the liberty to rebase the PR