[kad] Store addresses of provider records.

[romanb]

So far, provider records are stored without their addresses and the addresses of providers are obtained from the routing table on demand. I don't remember whether this was ever done on purpose or just an oversight as part of a larger amount of work. In any case, this approach has two shortcomings:

1. We can only return provider records whose provider peers happen to currently be in the local routing table.

2. The local node never returns itself as a provider for a key, even if it is indeed a provider.

These issues are addressed here by storing the addresses together with the provider records, falling back to
addresses from the routing table only for backward-compatibility with existing implementations of RecordStore that use persistent storage and may thus have records that persist across restarts.

Closes #1526.

[mxinden]

We can only return provider records whose provider peers happen to currently be in the local routing table.

Good catch. I have missed this to be honest.

Wouldn't the ProviderRecords need to be updated in inject_addr_failure and inject_address_change?

[romanb]

Good catch. I have missed this to be honest.

Wouldn't the ProviderRecords need to be updated in inject_addr_failure and inject_address_change?

I don't think that is necessary as provider records are regularly re-published. It may not even be desirable.

As for inject_addr_failure, just because one node cannot reach a certain address does not mean others cannot either. A provider may publish a bunch of addresses, different subsets being reachable by different nodes, depending on where they are located. This is not dissimilar to the addresses in the routing table where we do remove such addresses, except for the last one, which is a trade-off in favour of faster routing lookups in the general case, because these addresses are used so much more frequently in the iterative routing. In general, however, it is the job of the provider to tell others which addresses to store and advertise to others.

As for inject_address_change, even if a provider is generally ok with its addresses being updated without his direct instruction in this manner, I think a push-based approach would be more desirable. Meaning, a provider could re-publish its own provider records whenever his listen addresses change, but given that this is already done in regular intervals anyway, it is at best a nice-to-have.

Does that sound reasonable or do you have more serious concerns?

[mxinden]

Following up on the discussion above (#1708 (comment)):

it is the job of the provider to tell others which addresses to store and advertise to others.

That sounds plausible. Thank you for the detailed explanation.