We always had a very weird relationship between bitswap and providing.
Bitswap took care of doing the initial provide and then reprovider did it later.
The Bitswap server had a complicated providing workflow where it slurped thing into memory.

Reprovide accepts provides and is able to queue them in a database, such as on disk, this is much better.

I'll add options to hook initial provide logic from the blockservice to the reprovider queue so consumers don't have to do this themselves.

…bilities to an option of the client

Given that the previous commit remove the content advertising from the server, it did not made sense to share these paths on the network.

The code has been reworked:
- addresses aren't magically added to the peerstore as a side-effect of calling `Network.FindProvidersAsync`. Instead they are passed as hints to ConnectTo which copies libp2p `host.ConnectTo` API.
- the providerquerymanager is completely shutdown when not using `WithContentSearch` option, this helps usecase where `routinghelpers.Null` is used for content routing and the consumer exclusively rely on broadcast, like networks where most peoples have all the content (Filecoin, Celestia, ...).

This allows to recreate the behavior of advertising added blocks the bitswap server used to do.

blockservice is explicitely tolerent to having a nil exchange.
The constructor even logs that as running an offline blockservice.

Everything is except close, which panics.

It is confusing for consumers to only have to call close based on if it's online or offline.
They could also instead call close directly on the exchange (then we could remove blockservice's Close method).

Anyway here is as a simple fix, add a nil check.

Closes: #172
See #172 (comment) too.

providerQueryManager took care of:
- Deduping multiple sessions doing find providers for the same CID.
- limiting global find providers.

None of which we care:
- This is rare, if this happens it's fine to run the same query twice.
  If we care then we should make a deduping content router so we can inject it anywhere a content router is needed.
- It's fine to allow one concurrent find peer per session. No need to limit this at 6 globally after that, it's a great way to stall nodes doing many queries.