ipld(shares/getters): IPLD getter hangs while data is requesting for the second time

[vgonkivs]

IPLD can hang if the data is requested for the second time and it is not yet stored.

Steps to reproduce:

1. Request shares by namespaces for the first time. The data has not been stored before, so we fall to the IPLD getter and request it through the bitswap;
2. Request the same shares one more time. This time, we can expect to get the data from the store directly. If the data has not been stored yet, then we are falling to the IPLD getter and it hangs.

was found during running blob module test #2909

[distractedm1nd]

Investigating

[distractedm1nd]

Crossposting from #2914 :

Hmmm. The deeper issue here seems to be that IPLD is hanging on the second time (if we give store long enough to store, it gets from StoreGetter)

Our ideas here are:

Bitswap peers maybe have an anti-spam mechanism where the same block will not be served twice to the same peer, which is fine, but:
These blocks should be cached on the blockstore level and not actually rerequested from the network. This makes it seem like the caching mechanism from IPLD retrieval isn't actually working.

[distractedm1nd]

Can confirm that even when a full node is retrieving data over IPLD, Put is not being called on our blockstore, so nothing is even being inserted into the cache atm. Still unclear whether this is a swamp quirk or not