Add config profile endpoint and CLI

[dirkmc]

Fixes #2148

Depends on

• feat: tests for config profile endpoint ipfs-inactive/interface-js-ipfs-core#488
• feat: add config profile endpoint ipfs-inactive/js-ipfs-http-client#1030

[dirkmc]

The go implementation stores a backup of the config every time a profile is applied. I'm not sure that's necessary, @alanshaw do you think we need it?

[alanshaw]

FYI @dirkmc I have rebased and updated deps

[alanshaw]

Can these just be interface-ipfs-core tests?

[achingbrain]

I'm hesitant for two reasons:

1. We test to see if the profile was correctly applied by inspecting the config which requires the tests to have knowledge of what the profiles are - as implemented this would involve adding ipfs as a dependency of the interface tests which it is not currently
2. There are CLI features that aren't in the interface definition (for better or for worse) like listing available profiles

[achingbrain]

I've exposed profile definitions over the http interface so these can be moved now, hooray!

[alanshaw]

@hacdias @olizilla @lidel we're adding profiles to js-ipfs. I'd like to add a desktop profile - what would that look like? Is desktop the default? What changes to the browser config should we make? Should we also have a browser profile so you can switch to it in other environments? Are we missing any other profiles? Please help 🙏

[lidel]

Prior art in go-ipfs/docs/config.md#profiles:
There is no desktop profile in go-ipfs (yet?), for now we manually apply config changes via ipfs-desktop:

• ipfs-desktop/src/common/store.js#L13 (dht client mode, enable gc)
• ipfs-desktop/src/daemon/daemon.js#L71 (connmgr limits to avoid killing consumer routers, mdns on)

I think we could scope initial js-ipfs profiles to:

• server - similar to one in go-ipfs, disables preload, disables default signaling server, no dialing to local networks, no gc and mdns is also off (not sure about relay, perhaps relay should be a separate profile)
• desktop - settings applied by ipfs-desktop (mdns, dht client, gc on), in future could be also a relay client mode
• browser - enable preload, enable signaling via -star (in future relay), enable gc
• test - similar to one in go-ipfs: disables things like bootstrap, preload, mdns to speed up tests etc (would remove a lot of boilerplate in tests going forward)

Hope this helps as a starting point :)

[achingbrain]

Merged master into this PR to fix the merge conflicts. Still needs a bunch of work to address the PR comments and probably to integrate with #2428

[achingbrain]

I wonder if we could have an offline profile that didn't start a libp2p node at all? That would probably speed up the tests pretty dramatically as only a few of them actually require networking.

[achingbrain]

Anyone know why the method this adds is ipfs.config.profile and not ipfs.config.applyProfile?

To me at least, it's a bit more obvious what the second one is going to do.

[achingbrain]

Or better yet:

Promise<Array<{ name: String, description: String }>> ipfs.config.profiles.list()
Promise<void> ipfs.config.profiles.apply(name, { dryRun: Boolean })

[achingbrain]

The functions in my previous comment are implemented so the list of available profiles is now exposed over the http api.

Depends on:

• feat: add methods for listing config profiles ipfs-inactive/js-ipfs-http-client#1119
• feat: add test and docs for listing config profiles ipfs-inactive/interface-js-ipfs-core#536