kv: support computation of index field

[npry]

Allow specifying a closure to compute indices for a given value. By default, it just returns Some(value.clone()) (the current behavior), but you can return None if the value doesn't have a key for that index (such as Node::disco_key, which is optional) or multiple values if they exist and you know they're unique (such as the peer's tailnet ipv4 and ipv6, which are necessarily disjoint).

[nrc]

Looks good, thanks! Couple of questions inline

[nrc]

Is the use of IntoIterator future-proofing for multiple secondary keys per primary key (which I hadn't thought of, but I guess might be useful as well as multiple primary keys per secondary)? If not, then could we use Option rather than IntoIterator?

[npry]

The salient case in Peers is that there's an index on both the tailnet IPv4 and IPv6, which are both represented naturally as just IpAddr and are disjoint, so they can live in the same index. It's not like it's terribly onerous to just split them and use Option — if you'd prefer that I'm fine with it until we see a compelling need for a large or variable number of provably unique index keys

[nrc]

So there's one index IpAddr -> Peer where there might be 0, 1, or 2 IpAddrs per peer?

[npry]

It's always 2 in this case

[nrc]

We discussed this in a meeting last week. The use case is that the index is IpAddr -> Peer where each Peer has two IpAddr fields (4 and 6). The use of iterator supports this (or arbitrary numbers of foreign keys). Option is used for the 0 or 1 case and is simply converted into an iterator. In the future we want to support a foreign key mapping to multiple values as well as multiple keys mapping to one value, so we might need to revisit this design as part of that (for the peer use case, having separate indexes for ipv4 and 6 would also work but would be a bit less optimal).