Postpone the initialization of dynflow
In #18618, the initialization code was moved from foreman-tasks to foreman. There was however one
thing done differently, where the initialization of dynflow world was moved directly to the
time `Rails.application.dynflow` was called. This is not right, as there are situations where
plugins go and call `Rails.application.dynflow.config` before the whole stack is prepared, which leads to
database connection being opened too early, which can cause the whole lot of issues (as we've hit currently with Katello).
After we released #18673, the Katello tests started failing on
ActiveRecord::StatementInvalid: PG::ObjectInUse: ERROR: database "test_develop_pr_katello-2-test" is being accessed by other users DETAIL: There are 3 other sessions using the database.
That was due to fact that the dynflow world was initialized too early.