feat: secure subdomains for settings, improvements to server and login

[dr-frmr]

Problem

Secure subdomains had rotted just a bit from disuse. Also, we are exposing sensitive APIs via HTTP frontends in the core distro.

Solution

This PR cleans up the subdomain logic at the runtime level, and switches the settings:sys app over to actually using them. It goes along with a commit in the develop branch of process_lib.

However, we still serve sensitive APIs from the app_store:sys frontend. I would switch that over too, but the homepage currently relies on fetching from those sensitive APIs in exactly the way we want to make impossible. As a result, we will need to change the homepage logic to fetch that data using in-node capabilities-controlled messaging and switch app store to secure-subdomains in that PR.

Testing

• boot a node
• try accessing the Settings app
• you will need to log in again

Docs Update

TODO

[nick1udwig]

Tested, seems solid, very cool!

the homepage currently relies on fetching from those sensitive APIs in exactly the way we want to make impossible

lol

I wonder if we can somehow message to the user what is going on here with the subdomain-specific login screen. I don't think it needs to happen here, but it is something we should think about. As a user, I can imagine being confused why I am asked to enter password again.

[nick1udwig]

Ah, one other thing.

We should consider if we can make the secure subdomain denial messages more debug-able.

I can imagine a dev developing an app being very confused about what is going wrong and the current error messages are not very clear about what is happening.