Make Web UI work with the read-only API

[olizilla]

It's not well documented yet, but there is a "safe" subset of the IPFS HTTP API exposed on the Gateway port. Web UI should detect it and work with it so people can safely expose a subset of the functionality when hosting IPFS on a remote machine

You can see the read-only API in action on the Gateway:

https://ipfs.io/api/v0/version

The current definition of what's available is here:

https://github.com/ipfs/go-ipfs/blob/727bf49eff7ff61936aee6d4674ae3e7ad0aaddb/core/commands/root.go#L155-L187

[olizilla]

This will need

• An update to test ipfs-redux-bundle uses to determine if a connection works. Right now it use /id which isn't in the read-only api Use an api call from the whitelist to check if the http api is available ipfs-inactive/ipfs-redux-bundle#4
• We need a mechanism to determine the commands available, and permitted. We can use the /commands api when we have access to the http api. If we drop window.ipfs support Problem with window.ipfs and Files/Settings #787 then that'd be enough to get the list of api calls that could succeed and modify the UI accordingly. If we keep window.ipfs, then we need a mechanism to determine what permissions the user has granted. Meta: window.ipfs v2 ipfs-companion#589
• Multiple UI updates, to show disabled actions and to indicate the read-only state of the api available
• The deluxe solution to this is to review the UI and ensure there is a sensible disabled state for every api call, as the user could selectively disallow privileges via window.ipfs.

[olizilla]

ipfs-redux-bundle update to not use /id is ready for review ipfs-inactive/ipfs-redux-bundle#15

[olizilla]

Also of note, the dev domain webui.ipfs.io is configured with the /api routes for the read-only api from ipfs.io, so that fools our current webui + redux-bundle combo into thinking there is a full api available on the local domain, so it uses it, and then fails to get bandwidth stats.