Move this repo back into go-ipfs

[BigLep]

Done criteria: this repo's content is moved into ipfs/go-ipfs and this repo is archived/redirected accordingly.
Why important: makes it harder for contributors as have to have PRs often in this repo and ipfs/go-ipfs

[laurentsenta]

I took a shot at this here: ipfs/kubo#8756

Two questions:

• Is the timing right to push this further?
• Should we sync with other projects that relies on this?

The package is imported by 200+ other packages,
https://pkg.go.dev/github.com/ipfs/go-ipfs-config?tab=importedby

The ipfs ones:

• github.com/ipfs/ipfs-cluster
• github.com/ipfs/ipfs-cluster/api/common
• github.com/ipfs/ipfs-cluster/api/ipfsproxy
• github.com/ipfs/ipfs-ds-convert/testutil
• github.com/ipfs/ipget
• github.com/ipfs/iptb-plugins
• github.com/ipfs/iptb-plugins/browser
• github.com/ipfs/iptb-plugins/docker
• github.com/ipfs/iptb-plugins/local
• github.com/ipfs/rainbow
• github.com/ipfs/testground/sdk/iptb

[aschmahmann]

@hsanjuan do you have any concerns on how this will impact ipfs-cluster?

Generally I think this is a good idea and should be fine. As it is, basically every change to that repo has come from people working on go-ipfs and the repo is pretty tied to go-ipfs. If we feel the need for some backwards compatibility we can always choose to alias the exported types and functions in go-ipfs-config to go-ipfs/config with a deprecation to let people lag behind a little while they update.

[BigLep]

2022-03-03 conversation:

• Biggest concern is that the quic-go dependency in go-ipfs (which limits the versions of Go that it supports) won't impact the consumers that only have a config dependency on go-ipfs.

[hsanjuan]

@hsanjuan do you have any concerns on how this will impact ipfs-cluster?

I think the project will survive if this is merged back.