modified ntp script to hide the error related to cfggen during bootup

[kannankvs]

This PR is to handle the issue 3527.
When device boots up, NTP throws a traceback as explained in the issue 3527.

1. Traceback will be seen when MGMT_VRF_CONFIG does not exist in the database. Traceback is coming from the script “/etc/init.d/ntp”.
2. Traceback does not affect the NTP functionality with/without management VRF. When MGMT_VRF_CONFIG does not exist or when MGMT_VRF_CONFIG’s mgmtVrfEnabled is configured to “false”, “NTP” will be started in the “default VRF” context, which is working fine even with this traceback.
   3)This traceback error will be hidden by redirecting the error to /dev/null without affecting functionality.

-->
- What I did
Modified files/image_config/ntp/ntp file to redirect the error returned by sonic-cfggen to /dev/null.

- How to verify it
Rebooted device and verified that the traceback error is not seen in the journalctl. Tested NTP without management VRF and with management VRF and confirmed that it works fine.

- Description for the changelog
Modified files/image_config/ntp/ntp file to redirect the error returned by sonic-cfggen to /dev/null.

NOTE: The other issue reported in the issue3527 is related to LOOPBACK_INTERFACE|pfx_filter. That issue is a different issue which is not related to management VRF; it shall be replied accordingly and tracked in separate issue/PR.

[lguohan]

retest vs please

[lguohan]

it is better to avoid print out this traceback. can you print error message in sonic-cfggen saying the data[yyy] is not available to stderr? This can be a separate pr.

[kannankvs]

@lguohan : In this change, we are masking the stderr outside the cfggen. Can we assume that you would be merging this PR?
Regarding printing error message in cfggen, it is possible to print "data[yyy] is not available". But, all the callers of cfggen are not masking the stderr right? And, it is not good to have "ntp/MGMT_VRF specific" checks inside cfggen to mask only this particular error right? We have raised a git issue3755 to track this requirement, we shall discuss the same in that issue and raise PR later.

[lguohan]

let's discuss this in #3775