routing: Implement merge of nhgrp in new multipath route

[pouria]

Summary

Routing subsystem allows creating new multipath routes by
nexthop groups (e.g RTA_MULTIPATH in netlink), in case of
a second nexthop group on the same route, don't panic and
merge the existing nhgrp with new one.

[pouria]

For tests, see D56190.

sys/net/route/nhgrp_ctl.c

836–838

For reviewers, it's meaningless to reference nhops of an nhgrp here like above. Therefore, I didn't.

843–845

For reviewers, don't worry about the reverse order here, it will eventually sorted by qsort.

[pouria]

For reviewers: this patch also fixes a panic caused by an incorrect assumption in nhgrp_get_addition_group().
That function assumes rnd->rnd_nhop is not an nhgrp_object, therefore sending two or more RTA_MULTIPATH attributes can trigger a panic.

[pouria]

This comment was removed by pouria.

[glebius]

sys/net/route/nhgrp_ctl.c

662

The parenthesis around sizeof() are superfluous.

[pouria]

Address @glebius comment.

[melifaro]

Generally LGTM with the only comment above.

sys/net/route/nhgrp_ctl.c

642

The nexthop group contains next's and their relative weights. I'd rather try to have a single representation of all variants, where next hops are not duplicated,. E.g. if the merged list contains nehhops [(A, W1), (B, W2), (A, W3)] then it should be represented by the nhg (A, W1+W3), (B, W2))]

[pouria]

sys/net/route/nhgrp_ctl.c

642

Since part of the weight value is used for the metric (it was previously reserved for that), this would result in an incorrect metric because the metric value would be summed twice.
Also, we don't do this in append_nhops, so our compiled nhops become inconsistent.

We can fix append_nhops, but please also see my other revision, especially D56322.
After D56322, I can overwrite existing duplicate nhops with same metric but different weights.