auth: Initialization ordering of global objects is unspecified

[rgacogne]

• Program: Authoritative
• Issue type: Bug report

Short description

As reported by Coverity in several defects, we have a problem with the initialization order of global objects. For example, as reported in CID 1524949: Initialization or destruction ordering is unspecified:

• We have a global gSQLite3Loader defined in gsqlite3backend.cc
• the constructor calls Logger::operator<<()
• which calls S.ringAccount()

This means we need the global StatBag object S to exist before the gSQLite3Loader object is created, but we have no guarantee this will be the case.

I attempted to solve this in #13629 by turning StagBag into a singleton, thus ensuring it is created before being used. @fredmorcos went about it in a different way in #13613, by passing the StagBag object as a parameter to the functions that need it. While the second approach is cleaner, it might be difficult to do it at scale given how widespread the use of S is.

[fredmorcos]

The approach I took was not meant to be done entirely in one go. So it's alright if we fix things up bit by bit over time, where each of us could do a small part in this.

Ideally we completely get rid of globals, mutable or not, because they cause issues with other things like linking when we split up our codebase into libraries.