File system: explicitly support extensions

[ES-Alexander]

We should have a part of the file system dedicated to persistent data for extensions, such as configuration, logs, icons/logos, readme, and relevant user data.

Having a folder per extension would allow consistent binding rules, monitoring (to ensure data usage remains within user-specified limits), and clearing (e.g. when uninstalling, or as a refresh), and a fixed location (and filename structure?) for logs would make them easier to access and manage.

I recommend adding a shortcut (like the existing ones in the file browser), with extensions as the main folder, then docker-image-name for the individual extensions, which should include a logs folder for any logs, a readme file, an icon image file, a logos folder for company logos and the like (in case the user wants to include them in the upcoming logos section of the BlueOS interface), and anything else the extension wants to store.

Relevant to:

• We _need_ docker logs #1611
• core: frontend: support "sponsor" logos #1441
• Allow configuration of resource allocated per extension #1243
• core: frontend: extensions: Add icon on installed extensions #1231
• Kraken development tracker #1180 (logos and readmes)

EDIT: We ended up deciding the directory structure of the binding should be /usr/blueos/extensions/<extension_name>/.

[Williangalvani]

That is a very good idea. We could also mount the storage folder automatically, which would make the json simpler for extensions using it for trivial things

[ES-Alexander]

... We could also mount the storage folder automatically, which would make the json simpler for extensions using it for trivial things

This does seem convenient, but we'll need to think about a reasonable binding location within the extension - e.g. binding to root seems problematic, in case there are things the developer doesn't actually want accessible from outside the extension.

My QuickStart Python extension currently binds to /app, but I'm not sure if there's some better / more generic idea that would be preferable instead.