Support for read only server configuration directory

The following settings allow the server to use a read only configuration file:

The point of these settings is the configuration you want is locked down. Any change will not be saved upon a server restart, however it is possible to apply runtime changes that require a server reload. These settings are useful if the user has an approved configuration that must not be changed but he wants to test a different configuration without worring about the possibility to make the changes permanent.

However, neither of these configurations allow the server to start when the whole configuration directory is read only. During the booting phase the server needs write access to the configuration directory, for example, to store the history backups or temporal files.

History backups are senseless running on a container, and certain cloud use cases could require a non-writable storage mounted as a configuration directory, for example, by default config maps are mounted as read only volumes and a common pattern is to supply the server the configuration directory by using a ConfigMap. When we are running on a non-containerized environment, we could have very strict security rules that could force us the use of a read only configuration directory.

The goal of this feature is to make --read-only-server-config=<server config file name> setting work in standalone mode even if the whole configuration directory pointed by jboss.server.config is a read only directory.

Domain mode changes are not initially included on this feature.

The server configuration directory is currently used for the following files:

Under the use of --read-only-server-config=<server config file name> setting, the points 1) and 2) are covered for a read only configuration directory; the server configuration file and the initial logger configuration are not overwritten in this case, so they can be in a read only directory.

ApplicationRealm and ManagementRealm user/group property files need to be edited outside the server. There are not booting phase steps or runtime management operations that apply modifications on these properties files. That means, the files outlined in 3) are not affected if we are using a read only server configuration directory.

Usually, the users will use the add-user.sh script to edit them. It is the user responsibility to supply the final files in the read only configuration directory. Once the configuration directory is made read only, the uses of add-user.sh against the default files will fail. This point also affects to the cloud images. The cloud images can use the ADMIN_USERNAME / ADMIN_PASSWORD variables to configure the default ManagementRealm user/group. If we are using a read only server configuration directory, the uses of this environment variables will generate an error.

The remained cases 4) and 5) will be solved as follow:

A test for standalone mode will be added to the WildFly test suite. The test will verify that we are able to start the server by using the --read-only-server-config=<server config file name> setting and the configuration directory is a read only directory. The test will apply a runtime configuration and will reload the server verifying the runtime configuration we applied.

This RFE does not need any documentation. It is assumed this RFE complements the uses of the existing --read-only-server-config command line parameter enabling it to work when the whole configuration directory is a read-only directory.

Add the ability to --read-only-server-config command line parameter to cover the case when not only the server configuration file is a read only file but also when the whole server configuration directory is a read-only directory.