Consolidate IPFS Path libraries under boxo/path

[lidel]

How many clowns path deps can you fit in a clown car one line of code?

During review of Gateway API refactor from #176, I've realized there are cases, when we use three "path types" from three different libraries. This culminated in this fun one-liner:

imPath, err := NewImmutablePath(ifacepath.New(ipath.String()))

• ipath is https://github.com/ipfs/go-path (includes resolvers, see Allow injecting custom path resolvers. kubo#9750)
  • bonus: old vendored version in https://github.com/filecoin-project/lotus/tree/master/lib/oldpath
• ipfspath is https://github.com/ipfs/interface-go-ipfs-core/tree/master/path
• ImmutablePath is recent invention in go-libipfs/gateway because above did not provide a type for representing this state

Proposed path forward

Thoughts on deduplicating/consolidating under boxo/path?
It honestly feels like if go-libipfs has a purpose, it is to provide a solution for reusable things like this.

I feel we will make better Gateway API in #176 if we don't use ifacepath but use a single go-libipfs/path library that covers Path, Immutable and Resolved states with distinct types/interfaces.

I assume we want to follow "copy" strategy from #191 here, to minimize blast radius?

We could make this consolidation in steps, first switch gateway, so the public interface from #176 only uses types from boxo/path, and in the future switch namesys/kubo to that as well.

Things to look out for

During the consolidation, the following issues and Pull Requests from the relevant repositories should be taken into consideration.

• CIDs containing "/" cannot be parsed go-path#54
• Fix/remove deprecated logging go-path#29
• path: add ToCid API go-path#61
• Support relative paths interface-go-ipfs-core#15
• Path parsing, validating, and normalizing. interface-go-ipfs-core#33

cc @ipfs/kubo-maintainers for feedback (paths are everywhere, and as much as I'd like to clean this up, I don't want to add unnecessary work for anyone)

[hacdias]

I'm up for consolidating the three repositories/types into a single package in go-libipfs. I've also asked myself before why we need to have different path types and change between both in different places. I agree that we should follow a different strategy than for the remaining repositories as this is more of a merge and consolidation kind-of-thing so it's slightly different.

[guseggert]

I agree this looks like it could be cleaned up. I would wait for the consolidation dust to settle before merging refactors like this though, just to make it a bit easier for consumers to upgrade.

[BigLep]

Agreed. Lets get the "vX" release out that doesn't have any refactoring so there is a way for consumers to more easily update. Then cleanup/refactor.

[BigLep]

Here is the tracking issue for the over the "over the hump" release: #202 . This refactor won't get merged into main until after that issue is completed.