Add Nextcloud 30 & 31 support

[JonathanTreffler]

☑️ Resolves

• Fix Nextcloud 28 compatibility #22

This replaces the old removed NC systems (old event system) with their modern equivalents.
I also refactored any code that uses exec() as this command is forbidden and disabled in the environment I want this app to run it and not needed, this can all be done with easy native PHP.

🚧 Tasks

• migrate to new event system
• mark as compatible in info.xml
• test simple operations like l10n-override:list and l10n-override:add and if changes actually show up in frontend
• test more complex operations (disabling, enabling apps, ... ?)

🏁 Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• ⛑️ Tests (unit and/or integration) are included or not required
• 📘 Documentation has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[JonathanTreffler]

(Added DCO in force-push)

[JonathanTreffler]

I have so far tested on NC 31 with no reason to doubt it would run on NC 30, but I will also test that later.

[vitormattos]

Look the failed checks.

[vitormattos]

Also will be necessary bump the version:

<version>2.0.0</version>

Considering that is to be compatible with a newest version of Nextcloud server and considering the Nextcloud server as a framework, we can talk that it's should be a major increment.

What's you think about this? Maybe could be 3.0.0

[JonathanTreffler]

As there are no breaking changes to public interfaces per Semantic Versioning the correct version would be 2.1.0, but I personally would also be OK with 3.0.0, if you prefer that

[vitormattos]

Another point....

I know that could be a bit complex to make backports but we can set the min and max versionto 32 and after this, send the backport to a branch stable31.

We also can drop Nextcloud 30 because the official support by server will finish into September as we can see here: https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule

[JonathanTreffler]

Ah, I just realized I got the PR title wrong. NC 32 is not even out yet, i meant 30 and 31. And AFAIK apps should not mark themselves compatible with a version until that version is at least very close to a release.

[JonathanTreffler]

Is there any upside to going the backport way ?
I think normally this would be done when code changes to the app are needed between the two versions, so features can be backported to the old branch too.
Since this is only compatibility changes, no feature changes and no code changes between the versions are needed I think this approach would be simpler:
Releasing one version which covers both 30 and 31 and just drop NC 30 with any next release after September, when it is no longer supported.

[JonathanTreffler]

@vitormattos Could you please take a look at the updateAllLanguages function ? Before I changed it that function called $this->update() with 3 parameters, even though it only takes two. So I removed the parameter, whose name did not match by name.
But that was still not working as listLanguages does not return a list of languages as the name might imply, but a list of rows from l10n_override_text, so I assume the parameter that should actually be passed to update is the new_language column of that row ? I change that, now it does not throw errors anymore, but you probably know better what it was supposed to do and if this actually does that.