Rudder

Sometimes, we see a deadlock around boot time in rudder.
it seems to be more frequent with 7.3 (and so likely b/c of switch to zio 2).

Perhaps a reproduce is that it boil down to a much more maze like instance of an early init problem as minimized here : https://github.com/zio/zio/issues/8044

Since RudderConfig is growing very complicated and zio2 seems to be more agressive in creation of instance needed a lock, it is likely to be that.

The correct, principle solution to that problem is to a principle depency injection framework like zio layers. But it won't be even remotely compatible with what we have.

We could also come back to the "lazy val everywhere" solution that we used to use in early version of rudder but abandoned because it created surprises with late init of services (like batch not started or service init error lurking undetected before a very long time).

Plus, we have to keep the current existing RudderConfig API which is used pervasively in Rudder.

So, the solution is to split cleanly appart RudderConfig init from the init of other services/etc.

So RudderConfig needs to just assign all its public fields in one go by calling a method which does all the current init logic and returns all the initialized services in a data container class.

I'm not sure it's possible or if it will just add a level of turtles.