Allow individual config_db per host via ztp.json

[iljarotar]

Description

Initially, this PR was intended to enable a ZTP-only deployment for SONiC switches, such that all configuration currently handled by the sonic role could be managed entirely by ZTP. The motivation behind a ZTP-only approach is that the template for the config_db.json has become quite complicated and difficult to debug recently, because many special cases needed to be handled. With a ztp.json file it is possible to provide an individual config_db.json for each switch, which makes templating obsolete.

The downside to this way of provisioning is that the SONiC config cannot be changed via CI anymore, but only by resetting the switch completely. For the config_db.json, this seems fine to me, as it reduces the risk of breaking the switch by providing an invalid breakout config for example. However, providing the frr.conf file via ZTP doesn't seem a good idea to me and it would have introduced a lot of redundancy, because the sonic role also renders the frr.conf.

Therefore, I decided to make ztp.json only provide the config_db.json and some setup scripts, but leave the rest to the sonic role. To avoid conflicts with the config_db.json rendered by the sonic role, I introduced a new variable sonic_render_config_db_template which defaults to true, to not break existing deployments.

Noteworthy

It is now possible to provision SONiC switches with a static `config_db.json` provided through ZTP instead of rendering this configuration dynamically during deployment. This approach leads to more stable rollouts and might become our default for SONiC deployments. When using this new provisioning variant, follow the example in the `ztp` role documentation and set `sonic_render_config_db_template` in the `sonic` role to false. Also leave `sonic_ports`, `sonic_breakouts` and `sonic_portchannels` empty. Otherwise there might be conflicts between the provided `config_db.json` and the one rendered by the `sonic` role.

[robertvolkmann]

The PR should ensure that AgentX is enabled on the leaves.

[Gerrit91]

@mreiger yesterday brought up that it might be good to add a comment to the documentation that with this approach it is not possible to simply add something new to the config_db.json. Every change there requires re-provisioning the switch.