THe read() method in Config2018 (new ConfigAPI) read the config file this way:

• for each XML tag
  • get the definition in the model (ConfigManager2018)
  • use the definition's type to read the parameter value

This behavior is not OK because we want every parameter type to decide how it will be stored in the XML file. For exemple, a parameter could be an attribute of root tag, and not necessarily a tag itself.

The behavior to implement is this one:

• get the definitions in the model (ConfigManager2018)
• for each definition
  • use the definition's type to read the parameter value

With this behavior, there will be 2 notables consequences:

1. In the new API, we log a warning when there is something in the config file that is not used by a parameter. We won't be able to do that anymore. That's not a problem, this log didn't exist in the old API
2. With the actual behavior, we can make the difference between empty (we have an entry in the read() method result but the value is null) and not valued (we have no entry in the read() method result) parameters. This is useful in ConfigManager2018 _validateParametersForReading() method to invalidate parameters and start in safe mode if a parameter is not valued. With the new behavior, we won't be able to make this difference this way. The read() method on element types will be called for each defined parameter. So these methods will have to retrun something different if the value is empty (null?) or not valued (throw kind of ElementNotFoundException?) (see RUNTIME-2824)