Double down on hooks, remove app plugin in favour of individual hooks for individual capabilities

[rtibbles]

Goals

• Separate out device integration from more specific app functionality integration
• Allow app wrappers to initialize via configuration, rather than needing scripting to register against the previous app interface
• Allow a single Kolibri instance to run in both 'app mode' and not 'app mode' depending on the browsing context rather than whether the app plugin is enabled - this will allow more flexible usage on Windows and Linux where there is a need to be both an app and a server.
• Lean into Kolibri hooks for all configuration

Summary

• Cleans up deprecated abstractproperty decorators
• Adds a hook for adding plugins to the KolibriProcessBus
• Adds a class property to KolibriHook to check if any hooks are registered against it
• Deletes the app plugin and migrates all the capabilities registration to use KolibriHooks
• Creates two device hooks for GetOSUser and CheckMeteredConnection
• Creates a content hook for ShareFile
• Updates capability checking to be done in individual SPAs rather than a global app capabilities utility
• Reimplements the share file functionality that had been inadvertently removed in 0.15.x
• Creates a new development plugin that enables all app functionality with dummy handlers, and logs the initialization URL on startup
• Automatically runs with this plugin for development

References

Depends on #12874 to allow specifying an extra python path for the development plugin
Needed to support learningequality/kolibri-installer-android#197

Reviewer guidance

I feel like leaning into the hooks makes sense to have a single way to customize Kolibri - is there anything about this that makes this less obvious?

By separating out the specific functionality that is more 'app' versus 'device' oriented, it has made each implementation a little more bespoke - but it seems sensible to me that metered connection checking doesn't have to be exclusive to app mode - is the minor added fiddliness an issue?

With the addition of the server hooks, we could also turn ZeroConf integration into a plugin, which would allow us to turn it off slightly more elegantly - and in a swappable way so that on Android we can provide the multicast implementation via built in Android mechanisms. The other configuration that feels like could benefit from being pluggable is the restart hooks - should we push more into plugins/hooks rather than relying on options.py?

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.20.0.dev0_git.20260219011319.pex
Windows Installer (EXE)	kolibri-0.20.0.dev0+git.20260219011319-windows-setup-unsigned.exe
Debian Package	kolibri_0.20.0.dev0+git.20260219011319-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.20.0.dev0+git.20260219011319.dmg
Android Package (APK)	kolibri-0.20.0.dev0+git.20260219011319-0.1.6-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.20.0.dev0+git.20260219011319.zip
TAR file	kolibri-0.20.0.dev0+git.20260219011319.tar.gz
WHL file	kolibri-0.20.0.dev0+git.20260219011319-py2.py3-none-any.whl

[bjester]

Just posting some review-in-progress comments

[rtibbles]

Updated, rebased, and force pushed.

[bjester]

I see no red flags. Just one comment on the relocation of a file, which I can't recall the timeline of historical file organization changes in Kolibri and whether this predated it.

[bjester]

Is the relocation of this file still appropriate?

[rtibbles]

I have rebased it since we moved the frontend code around, I think - but I still need to rebase this again, so I can double check!

[rtibbles]

Yes, seems fine - just moving it out of kolibri-common because it's only used in learn.