[frrcfgd] Support for FRR configuration based on config DB events

[zhaozhenhong]

- Why I did it

1. Support for non-template based FRR configurations (BGP, route-map, OSPF, static route..etc) using config DB schema.
2. Support for save & restore - Jinja template based config-DB data read and apply to FRR during startup

- How I did it

Added a new script and corresponding service. Based on the settings in DEVICE_METADATA table, new service will be started along with the bgp container start. And when user changed the BGP or other related table entries in config DB, the daemon will run corresponding VTYSH commands to program on FRR.
Also added jinja template to generate FRR config file to be used by FRR daemons while bgp container restarted

- How to verify it

1. Add/delete data on config DB and then run VTYSH "show running-config" command to check if FRR configuration changed.
2. Restart bgp container and check if generated FRR config file is correct and run VTYSH "show running-config" command to check if FRR configuration is consistent with attributes in config DB

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[ghost]

All CLA requirements met.

[zhaozhenhong]

HLD: sonic-net/SONiC#544

[lgtm-com]

This pull request introduces 13 alerts when merging 288986c into c3202d8 - view on LGTM.com

new alerts:

• 4 for Unused local variable
• 2 for __eq__ not overridden when adding attributes
• 2 for Inconsistent equality and inequality
• 2 for Variable defined multiple times
• 1 for Unused import
• 1 for Duplicate key in dict literal
• 1 for Inconsistent equality and hashing

[pavel-shirshov]

@zhaozhenhong
Can you please make LGTM happy? You can find the report above.

[lgtm-com]

This pull request introduces 13 alerts when merging 2a5c58e into f3feb56 - view on LGTM.com

new alerts:

• 4 for Unused local variable
• 2 for __eq__ not overridden when adding attributes
• 2 for Inconsistent equality and inequality
• 2 for Variable defined multiple times
• 1 for Unused import
• 1 for Duplicate key in dict literal
• 1 for Inconsistent equality and hashing

[zhaozhenhong]

@zhaozhenhong
Can you please make LGTM happy? You can find the report above.

Fix has been added with latest commit

[lgtm-com]

This pull request introduces 3 alerts when merging e942575 into f3feb56 - view on LGTM.com

new alerts:

• 2 for Comparison of identical values
• 1 for Inconsistent equality and hashing

[venkatmahalingam]

@lguohan @ben-gale Please let us know the next step on this PR.
Summary:
In DEVICE_METADATA table, field bgp_template_config has been introduced to differentiate whether the config model is template based (e.g current bgpcfgd) or non-template based (new one which has all configs in config-DB and based on events from config-DB, FRR is updated thru VTYSH commands).

[ben-gale]

@lguohan @ben-gale Please let us know the next step on this PR.
Summary:
In DEVICE_METADATA table, field bgp_template_config has been introduced to differentiate whether the config model is template based (e.g current bgpcfgd) or non-template based (new one which has all configs in config-DB and based on events from config-DB, FRR is updated thru VTYSH commands).

I think this is the right approach if MSFT wants to partition out some of the changes from their world. Somewhere else I saw a proposal to define cloud vs. enterprise builds, and use this as a selector, but I think this is too broad, and will create arguments (i.e. what should be in cloud vs. enterprise?).

[zhaozhenhong]

retest Azure.sonic-buildimage please

[sameerdell]

@lguohan @pavel-shirshov @tahmed-dev - to get these changes in 202012 branch need help with the label. Dell doesn't have permissions to add label.

[tahmed-dev]

@lguohan @pavel-shirshov @tahmed-dev - to get these changes in 202012 branch need help with the label. Dell doesn't have permissions to add label.

Done!

[legolasCc]

@zhaozhenhong seems frrcfgd.py have problem in dependency processing between different config db tables. For example: step1 initial data with (BGP_GLOBALS, BGP_NEIGHBOR). step2 delete asn from BGP_GLOBLAS. result to BGP_NEIGHBOR data aslo removed from bgpd.conf. step3, restore asn again. router bgp {} vrf {} is success, while BGP_NEIGHBOR not.