Add the ability to save default values for CLI flags into config

[andrew]

There are some command line flags that I always use, for example, when setting up and running a package manager mirror you might run the following command:

ipfs add -r --progress --quieter --cid-version 1 --fscache --nocopy --inline --raw-leaves /data/apt

Similarly, if you're using a different chunker or hash function for a project, you'll want to pass the same --hash or --chunker to every command.

It'd be great you a user could set default values for those flags in their ipfs config. Perhaps under a Flags namespace?

ipfs config add Flags.cid-version 1
ipfs config add Flags.hash blake2b
ipfs config add Flags.raw-leaves true

I'd imagine if a user had a default value for a flag set in their config but passed a different value for that flag via the CLI then the passed value with override the default.

If this functionality existed, we could further extend it's usage to allow profiles to also add a number of default flag values, for example if there was some kind of package-manager-mirror profile that set a number of default flag values that had been found to be the best set of options for working with large linux package manager repositories.

Using a profile rather than just advising users which flags to set would allow us to improve/tune the profile in later releases and transparently migrate users on that profile to the best options for their use case when upgrading to the next version of IPFS.

[andrew]

Potentially related to #6526

[lanzafame]

@Stebalien @djdv I think we are starting to pile up a few config related issues and it may be worth creating a config design discussion and speccing out the requirements people would like to see from a config revamp

[Stebalien]

Design questions:

• Client/Daemon - The first design choice we need to make is whether we want to apply the defaults on the client or the daemon. Note: The IPFS daemon may run as a different user or even on a different machine.
  • If we apply it on the server, it could confuse clients (documented defaults wouldn't apply).
  • If we apply it on the client, we won't be able to specify server-wide defaults (not sure if we care).
• Configuration - If we apply these options on the client, we have several choices to make around how to configure them.
  • Config - We could use the normal config. However, ipfs config Flags.foobar would set a server-side option.
  • Client Config - We could create a client-side config just for the CLI. The downside is that this adds a new config file users would need to manage.
  • Environment Variables - This may be the simplest approach and it's pretty common on unix/linux systems. However, it's pretty opaque.
• Flags/Preferences - This feature is currently described in terms of flags but flags are command specific. We may want to define this in terms of "importer" defaults. However, if we do that, keeping all of this logic server-side starts to make more sense (i.e., how does this server import files by default).

Given the package managers use-case, what would make the most sense? I'm leaning towards:

• Configure on the server.
• Use the normal config.
• Configure "importers" rather than flags.
• Fix go-ipfs so it doesn't send defaults from the client.
• Update the command documentation to indicate that we defer to the server's defaults.