Handle SPs changing their PeerID

[bajtos]

In #31, we are adding a caching layer for MinerID->IPNI PeerID lookup to avoid making too many RPC API calls.

Miner peer IDs are not immutable. They don't change frequently, but when they do, we need to update our cached values.

[bajtos]

Also, after miner's PeerID changes, pieces that we could not look up in the IPNI reverse index/PieceIndexer using the old PeerId may become available under the new PeerId.

I think we don't need to worry about that yet, we can wait to see if this ever becomes a problem. I suspect we will discover bigger issues related to PeerID changes than this one.

[NikolasHaimerl]

Is this really an issue?
We use the PeerId only when we try to resolve a payload CID for a given piece CID. We do not store the Peer Id, only the retrieved payload CID. Does the payload CID change if the Peer ID changes?
If not then changes to a peer Id should not really be an issue for us.

[bajtos]

In my understanding, this is about timing. Consider the following sequence of events:

1. Miner has PeerID id1 and accepts a deal with PieceCID baga1.
2. PieceIndexer processes the advertisement and creates a mapping (id1, baga1) -> bafy1
3. Miner changes PeerID from id1 to id2 and announces a new advertisement chain.
4. PieceIndexer starts processing the new chain, but hasn't picked up baga1 yet.
5. deal-ingester maps miner to id2 and is looking up payload for (id2, baga1).
6. PieceIndexer does not have any payload for that tuple yet.

My take: this has a non-zero probability of occurring, which means it will eventually happen. However, the probability is so low that we don't need to worry about this for now.