chore: deprecate remaining dht query command

[lidel]

We've already deprecated all other ipfs dht commands, let's do the same here so it is in "Deprecated" section at https://docs.ipfs.tech/reference/kubo/rpc/ and users are discouraged to build things that rely on it.

We can always un-deprecate it.

[aschmahmann]

Why is this being deprecated when there are no alternatives (maybe you can kind of use one of the other commands incremental outputs but that seems kind of hacky)? Sure, it's a plumbing command users really shouldn't have to use but isn't that true of most of the DHT/routing commands?

[lidel]

We don't plan to remove it.

This PR is only about setting expectations, discouraging people from building things on ipfs dht APIs until we have time to clean them up. There is work remaining making ipfs routing and ipfs dht separate, and being able to runipfs routing against a specific router.

Having only this one in other place than the rest looks like a sore thumb:

In my mind this is similar to what we did with ipfs object: deprecating it but keeping it around until we have #4801 #4782, and/or betetr way to do basic patch (MFS is not a solution).

[aschmahmann]

You can, although "query" is fairly specific to DHT implementation internals. It doesn't really mean anything if you use it on say IPNI.

[guseggert]

This is a broader problem: we have generalized Kubo content routing but we still need implementation-specific tools such as "ipfs stats dht" (see #9482) and "ipfs dht query".

Broadly I see two paths: we can double down on this generalization, or simplify and remove the custom config stuff (give the ability to specify delegated routing endpoints, and that's it). In the latter case if users want something more sophisticated, they'd build their own binary from libipfs. We have a lot of work to do on the UX for that latter case, I don't think it's very good right now. But if we can cover the most common scenarios with a simplified config then that seems like a good path forward. If there's a long tail of custom scenarios users currently need, then I'd prefer the general approach because I don't want to pull the rug out from under them without a good path forward.

[guseggert]

If we want to stick with the generalization, then, as a starting point for discussion, I propose that we:

• Add the ability to poke at specific routers in the routing config
• Move everything to use routing config
  • So that even in the default case, "custom" is used under the hood and the routers have names and can be poked at individually

"Poking at specific routers" might look something like this:

ipfs routing --router <name> findpeer <peerID>
ipfs routing --router <name> findprovs <key>
ipfs routing --router <name> get <key>
ipfs routing --router <name> provide <key>
ipfs routing --router <name> put <key> <value-file>

ipfs routing --router <name> closestpeers <peerID>  # equivalent to current "query" command

If you leave off --router <name> then it uses the top-level router from the config.

If a method isn't implemented then it results in an error, so that non-DHTs return an error for closestpeers. Delegated routing impls may not impl all methods either like "provide", which is fine, that also would return an error.

[guseggert]

I don't think it makes sense to leave this sitting here since it's going to require a bunch of other work beforehand, we can't just turn this off. So I have opened this issue, we can track progress there: #9730