Correctly handle the last bucket when refreshing the routing table

[Stebalien]

As far as I know, we need to track last update times for all real buckets that get included in the last bucket. That way, we can properly refresh them.

[aarshkshah1992]

Let me see if I understand this correctly.

Say on peer P, the RT has 2 buckets with the 2nd bucket(B2) being the "catch-all".
Currently, even if we lookup a peer Px such that CPL(P, Px) = 5, we reset the refresh time for B2 even though we haven't looked-up a peer with a CPL of 1(the "actual" CPL for B2). Now, if B2 gets full & split & we later kick off refreshing, B2 will, incorrectly, not get refreshed.

The ideal behaviour would be to track refresh times for CPLs & not for buckets. In the above case, when we lookup Px, we will reset the refresh time for CPL[5] & not for CPL[1]. All of this of-course respects our "MaxPrefixLen 16" constraint.

@Stebalien Please let me know your thoughts & I'll come up with a PR.

[Stebalien]

Exactly!

And yeah, given that our max prefix length is 16, we only really need to keep track of the first 16 buckers. We can't query past that anyways.

[aarshkshah1992]

@Stebalien One concern here.

When do we start tracking a particular Cpl ?

1. Should we always refresh everything in Cpl[0-16] (if eligible of course) ?
2. Should we start tracking a Cpl after we have atleast one peer with that Cpl in our bucket ?
3. If we choose 2, we should also consider tracking a Cpl such that Cpl="catch all bucket ID" because the "catch-all" bucket could potentially not have any peers whose Cpl="catch all bucket ID".

I prefer 1 for it's simplicity & also because it ensures we have peers with varied Cpl's/XOR-distance-ranges right from the get go.

[Stebalien]

I think 2. Remember, we query for ourself first. That should let us find our closest peers. Once we know that, we should be able to calculate the highest CPL.

[aarshkshah1992]

@Stebalien This issue can be closed.

[Stebalien]

Thanks!