Implement a non-user standalone.sh extension mechanism

We have a reasonable architecture for how standalone.sh works: standalone.sh itself is not meant to be touched and has a lot of complex logic, and then standalone.conf is for users to manipulate as they wish to set up env vars. The standalone.conf is sourced early in the standalone.sh execution.

What's missing is a hook for non-user extensions to the standalone.conf concept. Primary use case being cloud containers where the container developers also don't want to maintain their own variant of standalone.sh but need to do env var manipulation before the main script logic runs. Right now images are handling this by shipping their own standalone.conf with a bunch of content appended, but that has the effect of making the file no longer a 'user' file.

A possible simple way to improve this is to have standalone.sh look for a 'standalone.conf.post' file and, if present, source it after standalone.conf. Perhaps a standalone.conf.pre as well.

(Tangent: I think our stock standalone.conf/bat etc should have a leading comment section explaining the "API" of standalone.sh, i.e. what are the env vars that standalone.sh will process that the user may wish to manipulate in standalone.sh.

kwills@redhat.com FYI and input. Whether this is a good idea in our images is a good thing to discuss; i.e. whether easing end-user manipulation is something desirable. The basic design is users should not do that, and instead they should use the various cloud-specific env vars processed by the image logic to manipulate the server launch. And I think that's fine/correct. I just don't like the way that image logic is implemented by having the image build append logic to standalone.conf. That's conceptually unclean.

jperkins-rhn jmesnil1@redhat.com FYI.

This is not urgent; just something I was thinking about after helping with some user issues with our image launch.