pinning + pathresolver: fix pinning/unpinning of sharded directories

[Stebalien]

• Change ResolveToCid to take a Resolver and a NameSystem instead of an ipfs
  Node.
• Make the pin/unpin methods use a Unixfs path resolver.

Closes: #3974

License: MIT
Signed-off-by: Steven Allen [email protected]

[whyrusleeping]

LGTM

[Stebalien]

We may want to hold this pending the discussion in #3910 (comment) (as it's possible to pin IPLD objects).

[whyrusleeping]

Hrm.... this is true. but the resolve is just being applied to the user given path. It shouldnt have any effect on pinning ipld objects.

cc @Kubuxu @lgierth

[Stebalien]

Can't you path through IPLD objects? Also, whatever happened to /ipld/.... Having the pathing scheme not declared somewhere in the path is kind of terrible.

[whyrusleeping]

You can path through ipld objects, that works fine. And shard nodes are very specific protobufs, so theres no ambiguity between a path in an ipld node and a path through a sharded node. The only issue happens when you want to address an intermediate shard element directly

[Kubuxu]

This construction is more and more frequent around, it might be good to store it in ipfs node struct or have helper for it.

[Stebalien]

At the end of the day, I think a better solution would be to avoid this resolver dance altogether. The root of the issue comes from the fact that the path doesn't dictate how it should be interpreted: as an IPLD path through IPLD objects (where the segments are keys) or an IPFS path through potentially sharded IPFS directories (where the segments are directory entries). To work around this:

1. It's up to commands to chose the initial resolver.
2. Resolvers do some additional magic under the covers to detect if a node should be treated as an IPLD or IPFS object by looking at it's Cid (they really shouldn't be doing this).

The solution I've proposed is to use separate prefixes: /ipld/... and /ipfs/... (ipfs/notes#248). I believe this is how this was intended to work (when designed) anyways.

If we did this, we could pass around the protocol along with the Cid/relative path so that core.Resolve and core.ResolveToCid could pick the right resolver for the given protocol.