Config reloading in Flying Passenger is broken

[FooBarWidget]

It looks like the Passenger 5 pool options cache, which was meant to improve performance, broke config reloading in Flying Passenger. Because most options are now cached, reloading the web server configuration has no effect.

We should introduce a command for clearing that cache.

Furthermore, it looks like environment variables set with passenger_env_var are cached and never updated. We should clear that cache too.

[CamJN]

High level process: finish converting components to config kit, and then expose an api for triggering a config reload & apply to configkit.

Details:

• configkit already supports update transactions, just need a way to trigger one.
• application pool is the main component not using config kit.
• the app pool has the job of creating app descriptions that don't exist or looking up existing ones (keyed by group name).
• the core receives the group name in a "!~" header, and looks up the app definition in the map
• currently the core also receives a bunch of other settings in the headers that are duplicated in the config manifest (from the fuse panel stuff).
• we should unify the source of configs (only the config manifest knows about all apps ahead of time, so that's the one to use)
• ideally the core would get the group name in the header and that's it, and then lookup the app in the dict which would be populated via the config manifest.
• currently the app pool when creating an app definition copies out settings and uses them to set other things, instead of referring to config kit (config kit has a cache, it's fast enough to use every time)
• not blocking, but either the generation or parsing of the config manifest is slow if there are many virtualhosts (see: Excessive Apache startup time when running many virtual hosts/rails applications #2098)

[FooBarWidget]

The structure that currently best represents per-app config, is ApplicationPool::Options. However this structure is incomplete: it only represents config that are relevant to ApplicationPool. So for example PassengerMonitorLogFile is not represented inside that structure, which is why in the AdminPanelConnector you had to hack around it by querying configGetter and inspecting the JSON.

Furthermore, there are two dictionaries that map the app group name to ApplicationPool::Options. There is one in Core::Controller (the poolOptionsCache, see Controller::initializePoolOptions()). There is another one inside ApplicationPool::Pool. Currently there is a function ApplicationPool::Group::mergeOptions() which tries to merge any relevant (and changeable) differences between the two, but this entire approach is quite a nasty hack and I don't recommend continuing to use this approach.

I'll leave it up to you to think of a proper design. The easiest way would be to cram everything into ApplicationPool::Options, but that would violate separation-of-concerns. I haven't given a good thought yet about what would be a more elegant design, but that will no doubt be a bigger effort.