Fixing problem ACP2E-2198.
```
[Progress: 861 / 864]
Disabling Maintenance Mode:
In ResourceConnection.php line 162:
[DomainException]
Connection "default" is not defined
```
The root cause of problem is that the `Disabling Maintenance Mode` part of the install uses the first created DeploymentConfig object created in the process, which doesn't get updated, while before that runs, different part of the install that writes to the config is using the second DeploymentConfig object that was created by Laminas ServiceManager. The reason why this happens is because Intercepters use ObjectManager::getInstance to get the ObjectManager to find PluginList. This causes the plugins to use the first DeploymentConfig object which was created for the first ObjectManager. Other objects that use ObjectManager::getInstance may have this problem as well.
This commit adds a workaround in main loop of Installer that calls DeploymentConfig::resetData() on the original DeploymentConfig.
This reverts commit a731903ceab6881ca09875eb434a7bc4c5568f9d.
This workaround didn't work for very specific use-case of custom 'etc' path when running setup:upgrade. This was found in setup-integration tests. The reason why it didn't work is because the first DeploymentConfig doesn't use the custom paths for 'etc', so it was loading the wrong files. This problem may still exist for plugins and other objects that use the original ObjectManager's DeploymentConfig instead of the DeploymentConfig object created by Laminas ServiceManager.
Fixing problem ACP2E-2198.
```
[Progress: 861 / 864]
Disabling Maintenance Mode:
In ResourceConnection.php line 162:
[DomainException]
Connection "default" is not defined
```
The root cause of problem is that the `Disabling Maintenance Mode` part of the install uses the first created DeploymentConfig object created in the process, which doesn't get updated, while before that runs, different part of the install that writes to the config is using the second DeploymentConfig object that was created by Laminas ServiceManager.
This commit causes Laminas' ServiceManager to use the same DeploymentConfig object as the first Magento ObjectManager used in the process, which resolves the issue seen in setup:install.
Rajesh Kumar