clarify lifecycle of the »Vessel«

[Ichthyostega]

As Lumiera Architect,
I want all aspects of lifecycle well defined and handled precisely,
to ensure the overall structure of the application is well understood and plumb.

analysis of dark corners required

Initially the »application« was projected as a conglomerate of components, that all just need to be pulled up, flexibly and on-demand. And shutdown was deemed not necessary — as long as everything is always maintained in clean state, it suffices to „pull the plug“.

While the principles behind this approach seem commendable, it turned out that an application of this weight and complexity was not so easy to maintain. A core application was gradually established, and now the application is understood as a vessel, with clear boundaries and a backbone.

However, the audacity of the early days has left its mark: there is an unclear quagmire of dependencies between NoBug, AppLifecycle, the LifecycleRegistry, the lib::DependFactory, SyncClasslock and the unexpectedException-handler

Guidelines

• everything of a coordinating nature belongs into the Vessel, not the Library
• Library code should not expose automated management functionality
• an internal backbone can not be an external interface

[Ichthyostega]

An initial investigation implies the following changes

• the ON_BASIC_INIT functionality of the LifecycleHook should be reconsidered, in light of the findings in #1133. It looks like a clumsily implemented and incomplete Schwartz counter
• there seem to be only two usages of that feature:
  • nobug-init.hpp
  • install_unexpectedException_handler() in error-exception.cpp
• nobug-init.hpp seems ill-guided, in terms of architecture; as far as I can see, with the introduction of ZombieCheck, none of the problematic low-level-features needs any logging during the static-init/shutdown phase
• maybe ZombieCheck should additionally also print the warning message to STDERR
• with these problems out of the way, LifecycleHook could migrate up into the »Vessel«

---

Another related theme is the usage of lib::DependFactory. This clearly seems to be a facility that belongs into the »Vessel«. Not counting the confusion around SyncClasslock and nobug-init, there seem only three further usages from Library code:

• the MultiFact — which in turn looks like an obsolete pipe dream from the early days ... it is used by the handling-patterns.hpp, which were never really implemented (and likely never will); and it is used from the query-resolver.hpp, which is a placeholder code for some not-yet implemented »centrepiece«
• the test/tracking-allocator.cpp uses some singleton pools for captured tracking information. This is a pattern that I would not implement this way any more. Rather, the user should explicitly create an instance of some diagnostics context
• visitor-dispatcher.hpp also exposes a singleton manager object, which implies it should move up into the »Vessel«