Allow app to specify it doesn't work with user key server side encryption

[rullzer]

It would make sense if apps can specify they do not work with server side encryption with user keys.

Apps that run not as the user (previewgenerator, richdocuments for example) have now have to somehow hack around this.

1. Preview generator just blocks when encryption is enabled
2. Richdocuments makes sure files are encrypted with the system key (so as if they are publicly shared)

Both are not ideals and add a lot of weird code.
Apps should not have to care. I don't want to write a lot of encryption checks for apps. I just want to write code with our APIs. So if somebody uses user keys they can't use my app.

@schiessle @nickvergessen @MorrisJobke input please :)

[nextcloud-bot]

GitMate.io thinks possibly related issues are #10120 (allow to disable encryption), #10121 (allow to disable encryption), #9368 (Encrypt appdata when using server side encryption with master key), #4531 (Allow app to specify dependency on other app), and #6350 (does not allow me to create users).

[MorrisJobke]

Makes a lot of sense to indicate this to the admins. Should this be an indicator in the info.xml? What happens if the app is enabled first and then encryption is enabled? Should it be automatically disabled or the activation of encryption being blocked?

[rullzer]

Yes I think info.xml is the right place for this.

Regarding enabling encryption I would vote:

1. Show a list, those apps will be disabled once you enable it
2. Disable the apps automatically then.

[MorrisJobke]

Regarding enabling encryption I would vote:

Show a list, those apps will be disabled once you enable it
Disable the apps automatically then.

I would vote for:

• you can't enable encryption until those incompatible apps are disabled

[nickvergessen]

I would vote for:
you can't enable encryption until those incompatible apps are disabled

Sounds much easier and more convinient

[rullzer]

Fine by me :)