ipld: Drop IPFS plugin support

[Wondertan]

What

Right now, we follow all the best practices of IPLDv0 in IPFS, which mainly includes registering our IPLD NMT in https://github.com/celestiaorg/celestia-node/blob/main/ipld/plugin/nmt.go#L53-L68 what essentially enables go-ipfs pluggability, so that go-ipfs can understand out NMT data type. However, we don't use IPFS anymore, and we went deeper into its guts to use what we need specifically. What I am proposing here is to take one small step further into its guts to solve some of our problems.

Why

There are a few reasons why we would consider this:

• This solves Blocker for updating libp2p/ipfs libs #306 for us. That is, we can avoid updating to the latest IPLD to remove the blocker and enable valuable libp2p dependency updates.
  • Specifically, registers linked above are changed with new IPLD and require us to change our data model to keep registering, while we can just drop the registering instead of continuing support for it.
• We are moving in the direction of implementing our own protocol for data transfers, so that we don't really need idiomatic IPLD compatibility and especially go-ipfs pluggability/compatibility anymore.

How

By going deeper into guts, I mean to rely on an abstraction below ipld.DAGService which is Blockservice. This way we can avoid those global registering and rely on our NMT IPLD implementation directly so that we use IPLD only for serialization of NMT not to reinvent the wheel. This way, we will start working with Bitswap directly without any facades, until we design our own data transfer protocol.

[liamsi]

This seems very reasonable as we definitely want to unblock us on updating to the latest libp2p sooner than later.

It would be nice if we can keep in mind that it might be useful to have IPFS as a storage layer long-term though. Here, compatibility is not super urgent nor critical but it's nice as we got this for free so far. My understanding is that we will be compatible once we've upgraded to ipldV1 anyways though.

[renaynay]

Agree with @liamsi

[renaynay]

And this :) #112