bgpd: fix memory leak in vni table for evpn routes

bgpd: fix memory leak in vni table for evpn routes

There is a memory leak of the bgp node (route node)
in vni table while processing evpn remote route(s).

During the remote evpn route processing, a new route
is created in per vni route table, the refcount for
the route node is incremented twice. First refcount
is incremented during the node creation and the second
one when the bgp_info_add is added.

Post evpn route creation, the bgp node refcount needs
to be decremented.

Ticket:CM-26898,CM-26838,CM-27169
Reviewed By:CCR-9474
Testing Done:
In EVPN topology send 1K MAC routes then check the memory footprint
at the remote VTEP before sending 1K type-2 routes
and after flushing/withdrawal of the routes.

Before fix:
-----------
Initial memory footprint:
root@TOR1:~# vtysh -c "show memory" | grep "Hash Bucket \|BGP node \|BGP route"
Hash Bucket                   :       2008      32
BGP node                      :        182     152
BGP route                     :         96     112

With 1K MAC (type-2 routes)
root@TOR1:~# vtysh -c "show memory" | grep "Hash Bucket \|BGP node \|BGP route"
Hash Bucket                   :       6008      32
BGP node                      :       4182     152
BGP route                     :       2096     112

After cleaning up 1K MAC entries from source VTEP which triggers BGP withdraw
at the remote VTEP.
root@TOR1:~# vtysh -c "show memory" | grep "Hash Bucket \|BGP node \|BGP route"
Hash Bucket                   :       4008      32
BGP node                      :       2182     152   <-- Here 2K delta from initial count.
BGP route                     :         96     112

With fix:
---------

After 1K MAC entries cleaned up at the remote VTEP, the memory footprint
(BGP Node and Hash Bucket count) is equilibrium to start of the test.
root@TOR1:~# vtysh -c "show memory" | grep "Hash Bucket \|BGP node \|BGP route"
Hash Bucket                   :       2008      32
BGP node                      :        182     152
BGP route                     :         96     112

Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>