Remove CBS/consul dependency for application config management

Under DCAE transformation to Helm initiative (REQ-1038/DCAEGEN2-2773), DCAE Cloudify Platforms components and Consul will be deprecated for Jakarata release.

In the new DCAE architectecture, configuration for DCAE services will be managed through combination of ConfigMap and SDK integration and dependency on Consul/CBS is being removed (refer DCAEGEN2-2692 for details)

As Holmes is dependent on legacy CBS api's for config retrieval, it will be impacted when CBS/Consul deployment is turned off in Jakarta release.

This Jira is for Holmes to remove CBS dependency. 

 There are two options to consider

1. Move all your application configuration to be loaded as ConfigMap and mount into POD as file which Holmes application can periodically refresh (when there is change in configmap then K8S will update the mounted file automatically).  This could be useful for post deployment Holmes configuration updates (which can be triggered via kubectl/helm upgrade etc)
2. Majority of DCAE MS has been migrated to use latest CBS client library (https://git.onap.org/dcaegen2/services/sdk/tree/rest-services/cbs-client) which has been enhanced to lookup  local configfile rather than invoking CBS API (details here - https://jira.onap.org/browse/DCAEGEN2-2716; the remainder of DCAE MS will be switched to use this library in jakarta to remove consul dependency).  One pre-requisite here to ensure configmap gets mounted in expected path and ENV exposed so SDK knows where to locate the config file. We have also standardized the configmap creation and mount part of dcaegen2-services common template (https://git.onap.org/oom/tree/kubernetes/dcaegen2-services/common/dcaegen2-services-common/templates/_deployment.tpl) which gets invoked from DCAE-services template (example here - https://git.onap.org/oom/tree/kubernetes/dcaegen2-services/components/dcae-ves-collector/templates/deployment.yaml). You may leverage them also for Helm charts if required and use the SDK library.