plugin architecture

[systemcrash]

• This PR is not from my main or master branch 💩, but a separate branch ✅
• Each commit has a valid ✒️ Signed-off-by: <my@email.address> row (via git commit --signoff)
• Each commit and PR title has a valid 📝 <package name>: title first line subject for packages
• Incremented 🆙 any PKG_VERSION in the Makefile
• Tested on: (architecture, openwrt version, browser) ✅
• ( Preferred ) Mention: @ the original code author for feedback
• ( Preferred ) Screenshot or mp4 of changes:
• ( Optional ) Closes: e.g. openwrt/luci#issue-number
• ( Optional ) Depends on: e.g. openwrt/packages#pr-number in sister repo
• Description: (describe the changes proposed in this PR)

Global enable for all plugins and enable for specific plugin classes

This introduces a plugin system for the UI - primarily to configure the behaviour of ucode plugins - and some example plugins.

This should cover the user-case for @josteink in #8161.

Some additional hook points are necessary to take care of 2FA type plugins for @Tokisaki-Galaxy and #8280 and #8281, I think.

[Tokisaki-Galaxy]

Hi systemcrash,
Amazing design! Iam happy to help add the auth mechanism hooks once the UI/UX part is settled.
One question: since UCI configs aren't removed when a plugin file is deleted, how should we handle "ghost" configurations? Currently, if a plugin file is missing but the config remains, it might lead to orphaned entries or even UI rendering errors (like in s.sectiontitle).

[systemcrash]

If the js plugin is gone - the UI portion doesn't show. You can take this PR for a test-drive to see how it behaves. So remaining config isn't a problem to worry about. Users might notice it when they look in the config files tho.

[stangri]

Thanks for this — the architecture itself looks interesting and the HTTP header example is a solid use case.

One naming concern worth raising: LuCI already has a well-established term for optional, independently installable UI components — "applications" (luci-app-*). In many other ecosystems (browsers, VS Code, WordPress), "plugin" is the common word for exactly that same concept, which already causes occasional confusion when people come to OpenWrt from those environments.

Introducing "plugins" as a new term here — even for a technically distinct thing — risks compounding that confusion rather than resolving it. Would it make sense to stay within the existing "applications" vocabulary and perhaps qualify it (e.g. "system applications", "core applications") rather than adding a second term that overlaps with what users already call luci-app-* packages?

[systemcrash]

Thanks for raising these concerns @stangri. I see what you mean.

The luci-app-* paradigm is a UI layer for an app dependency found in another repo, as per standard structure. It's possible to write an app which contains plugins, or is exclusively a plugin, since path structure determines the plugin, as long as it's ucode and fulfils plugin properties.

Having a distinct grouping differentiates them: they're (can be) independent of apps from other repos and are intended to augment UI behaviour. Their initial use cases being HTTP headers and 2FA stuff. Other hook points are possible, e.g. in the luci script which determines features (a la dnsmasq).

[systemcrash]

Now in master.