Support ConfigDB neighbor configuration, introduce nbrmgr daemon

[prsunny]

What I did
Initial commit to support ConfigDB neighbor table configurations

Why I did it
Requirement to resolve mac address for a configured neighbor IP. Also support static neighbor configuration

How I verified it
Logs:

Resolve case:

{
    "NEIGH": {
        "Vlan100|100.1.1.3": { 
            "family": "IPv4" 
        }
    }
}

19:01:02.216254 ARP, Request who-has 100.1.1.3 tell 100.1.1.1, length 28

Static Nbr:

{
    "NEIGH": {
        "Vlan100|100.1.1.5": { 
            "neigh": "00:02:02:03:04:05",
            "family": "IPv4" 
        }
    }
}

[admin@str-a7170-acs-1 ~ 08:10 PM]$ ip neigh show 
100.1.1.3 dev Vlan100  FAILED
100.1.1.5 dev Vlan100 lladdr 00:02:02:03:04:05 PERMANENT

Details if related
This is the initial commit for phase 1.
For phase 2:

1. Combine nbrmgrd and neighsync.
2. Address any priority items from Fix potential blackholing/looping traffic when link-local was used and refresh ipv6 neighbor to avoid CPU hit sonic-buildimage#1904 (comment)

[pavel-shirshov]

Is it possible to use libnl3 for netlink programming?

[pavel-shirshov]

as comments

[jipanyang]

In the case of mac address of the neighbor is empty, how would neighmgr handle warm restart/warm reboot scenarios? Some cooperation with neighsyncd seems necessary.

[pavel-shirshov]

Approve from my side. Please check Jipans' comments

[prsunny]

@jipanyang, as mentioned in description, plan is to merge neighsyncd and neighbor manager in next phase. I'll consider the warm-restart scenarios along with that. For the current use-case, we can skip the warm-restart requirements.