gateway: make API commands configurable

[ghost]

This is for Delegated Routing in js-libp2p (ipfs/js-ipfs#1459 & libp2p/js-libp2p#120) and supersedes #4595.

It lets us configure the commands available through :8080/api/v0/ -- for delegated routing, we would then e.g. expose swarm/connect, refs, dht/findprovs, and dht/findpeer.

By default, Gateway.APICommands is empty, which means go-ipfs will use the default :8080 commands.

> ipfs init
> ipfs &
> curl localhost:5001/api/v0/config?arg=Gateway.APICommands | jq -r .Value
[]
> curl localhost:8080/api/v0/commands | jq -r .Subcommands[].Name
dns
version
commands
cat
get
dag
refs
block
ls
resolve
name
object
> killall ipfs

> ipfs config Gateway.APICommands --json '["config"]'
> ipfs daemon &
> curl localhost:8080/api/v0/commands | jq -r .Subcommands[].Name
config
commands
> killall ipfs

[ghost]

Whoops, totally forgot updating the go tests. otherwise still happy about review :)

[ghost]

I am pretty sure that sharness t0236-cli-api-dns-resolve.sh is failing on Jenkins because of a nc or ipfs process leaking on the worker.

[ghost]

This one is ready for review

[keks]

Why don't you do this inside the loop (at line 64, where you currently set commands to true)?

[keks]

Hm, so you unconditionally create a new subcommand mal. That confuses me. Because if you have e.g. both dag/get and dag/resolve in allowed, you would overwrite dag and delete dag/get when adding dag/resolve.
Checking the tests now to see why this passes.

[keks]

I updated the tests and now they fail. Could you fix this?

[ghost]

It will be much simpler to back delegated routing by a modified branch of go-ipfs, so I'm closing this PR.

• Guarding security-relevant commands with configuration is more risky than simply avoiding code paths leading to them. Safest to just keep this a codified map as is.
• The configuration code I wrote here turned out pretty complicated, best to just throw it away.
• There's additional potential for problems whenever we change the set of commands exposed by default. Every new config option also potentially complicates future repo migrations, and this one feels like it does so significantly more than others.

[lidel]

@lgierth did this ever land in some other PR? was there anything more to the story?

We were trying to use Gateway.APICommands in context of ipfs/js-ipfs#2155 (comment) but it did not work, and @mburns had to redirect to API port at Nginx level.

[Stebalien]

We never did.