Sandboxing for MFS, Keys, IPNS

[hacdias]

With the addition of #10187, the next natural step is to allow sandboxing for the different APIs according to the given Authorization keys. At the moment, the following are identified APIs that should be sandboxed:

• MFS: each application will have their own MFS that does not collide with others.
• Keys: each application can only see and access keys that they have created.
• IPNS: each application can only interact with keys that they own (related to above).

This will be useful for applications built on top of the new authenticated API.

Easiest solution is to prepend some path to MFS paths and key names.

cc @lidel if you want to add more context

cc brave/brave-browser#34000 as Brave would like to use this for sandboxing access per blessed extension like https://webrecorder.net/

[lidel]

To elaborate a bit more, we want API.Authorizations value to have a Sandbox Flag which ensures the access token will provide a virtual sandbox that ensures out-of-the-box isolation between apps.

Initial design idea

Prefixing is worth exploring, as it saves us from refactoring too much, and works with existing tooling and RPCs.

If API.Authorizations have entry with key value appname:

• MFS (ipfs files) the / root visible to the sandboxed app is /___/appname/ subdir
• Keys (ipfs key) only shows keys prefixed with ___/appname/; by default app has no keys and when it generates one, the name is prefixed with ___/appname/
• IPNS (ipfs name publish --key keyname) only accepts keys visible via ipfs key list, errors when there is no ___/appname/keyname

___ prefix is a placeholder, ideas welcome, but starting with at least one _ ensures sandboxed entries are always listed together when sorted.