Add dedicated API for apps' bootstrapping process

[ChristophWurst]

Fixes#20573

Possible registrations (ticket=implemented there, rest follows in other PRs)

• Capabilities
• Services (for DI)
• Aliases (for DI)
• Parameters (for DI)
• Event listeners
• Middlewares
• 2FA providers
• Crash reporters (Sentry) Allow crash reporters registration during app bootstrap #21457
• Commands
• Notifiactions stuff
• Search providers for Add unified search API #20916

Possible ideas for the register or boot context

• Version of Nextcloud (e.g. to only call registration on things that are really available)
• CLI or web request flag

[ChristophWurst]

apps/comments/lib/AppInfo/Application.php is the new show case example for the new registration style 🕺

[ChristophWurst]

we don't have to do this here. we could actually either wait until right before the first boot method invocation or when the individual services are used

[rullzer]

I like it.
I guess we should merge this sooner rather than later. I'm still not 100% sure how to handle disabled apps for users.

But I gues we should start to do that differently anyways. And revamp that. So that it actually works as expected.

[rullzer]

🚀 lets do this!

[kesselb]

Looks good to me 🚀

• Commands

Good idea. I have a suggestion for the command implementation: I looked at https://symfony.com/doc/current/console/lazy_commands.html to make occ faster. Eventually loading the apps is the expensive step and not to create all those command objects itself but it's still a good thing to do (because if one calls occ maintenance:repair we only need the RepairCommand object).

Here is a POC https://github.com/nextcloud/server/compare/enh/occ-lazy-load?expand=1. The basic requirement is that the name of the command is known before creating the object. Please consider to make the command name a required parameter for the command registration. That makes migration to lazy commands much easier and ensures that apps using the new way to register a command do it right.

[ChristophWurst]

Makes sense, @kesselb. What I would also like to experiment with is proxy services instead of getting the real thing through constructor injection. Because right now you always build this huge tree of instances, when you'll most likely only every use some branches of that. Pimple, however, does not support it right now.

The commands are only slowing down occ operations, right? I hope we don't load them for web requests.

Looks good to me rocket

Mind pressing the approve button? :P

[nickvergessen]

Gotta love this "git rename" ....

[nickvergessen]

Looks good, didn't check to deeply nor transition over an app. But let's do it early.

[kesselb]

I would like to withdraw my suggestion for commands. It's good to have all the commands definitions in appinfo.xml. If we add a attribute like <command name="mail:account:diagnose">OCA\Mail\Command\DiagnoseAccount</command> we are able to load only the required app for a occ command similar to what the router does with routes.php.

The commands are only slowing down occ operations, right?

Yes

I hope we don't load them for web requests.

No

Actually creating the command instances is not the expensive task. Loading all apps is the expensive one.