bgpd: fix wrong 'pending' labelpool counter value at startup

If BGP starts with a l3vpn configuration, the 'pending' value
of the 'show bgp labelpool summary' command is set to 128,
whereas the 'pending' value is 0 if the l3vpn configuration is
applied after.

with no config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger:       1
> InUse:        1
> Requests:     0
> LabelChunks:  1
> Pending:      0
> Reconnects:   1

with config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger:       1
> InUse:        1
> Requests:     0
> LabelChunks:  1
> Pending:      128
> Reconnects:   1

BGP configuration is applied, the label request performed fails,
because the zapi connection with zebra is not yet up. At zebra
up event, the label request is done again, the 'bgp_lp_event_chunk()'
call decrements the 'pending_count' value. Then, the value is
modified to the expected 'labels_needed' value. This method was correct
while the label request call was asyncronous, because in this case,
the label allocation is obtained at the return of the label request
function.

Decrement the expected 'labels_needed' value instead.

Fixes: 0043eba ("bgpd: Use synchronous way to get labels from Zebra")
Signed-off-by: Philippe Guibert <[email protected]>

bgpd/bgp_labelpool.c

@@ -667,8 +667,7 @@ void bgp_lp_event_zebra_up(void)
 	if (labels_needed && !bgp_zebra_request_label_range(MPLS_LABEL_BASE_ANY,
 							    labels_needed, true))
 		return;
-
-	lp->pending_count = labels_needed;
+	lp->pending_count += labels_needed;
 
 	/*
 	 * Invalidate any existing labels and requeue them as requests