Do not have local ccdb URL parameters in configKeyValues initialized from NameConf

[davidrohr]

@shahor02 : This scheme of having one ConfigurableParam initialized from another one is conceptionally broken. It becomes a race condition which one is populated first, thus it is not well defined if the default value is taken, or the value after parsing the --configurableParam option.

This PR does away with ccdb settings in other configurableParams and uses the NameConf::CCDBServer for all.
I am not sure if this is the correct thing to do. It basically means that within one processor one cannot access different CCDB servers. But I don't see another way right now that is somewhat clean.
This will hopefully be solved once we have the proper CCDB API.

@sawenzel : In general, perhaps we should add a protection that no instance can be created before the parsing has happened?
Some days ago I also had a similar problem that someone was caching a value from a ConfigurableParam in a static variable, and that static variable was initialized at application startup time from the instace before the command line arguments were passed, so it hold the default value, and I could not set it via --configKeyValues. We should avoid such misleading behavior.

[shahor02]

Hi @davidrohr

Right, did not think about that. We still can have a possibility to have set e.g. DigiParams::ccdb and NameConf::mCCDBServer to different servers by setting the CCDB strings in all ConfigurableParams except NameConf::mCCDBServer to "" and adding methods like

const auto& DigiParams::getCCDB() {
  return ccdb.empty() ? o2::base::NameConf::getCCDBServer() : ccdb;
}

[davidrohr]

Yes, sure, we can do that. Shall I change this PR accordingly?

[shahor02]

Not sure we really need this, these few configurables which you have fixed had CCDB setting because there was no central one rather because they need special settings. I would leave this PR as is, once we switch to DPL ccdb server, we will have a possibility to set even each object server individually.