Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1493046

Description of problem:
In satellite 6.3, the time for everything to be ready to respond
to http requests or handle tasks is significantly longer than in 6.2.
This leads to potential initial timeouts when trying to register
a host after the installation finishes or after restarting of services.

Steps to Reproduce (a):
1. systemctl restart httpd
2. wait until the /users/login is available

Actual results:
It takes about 2 minutes to be ready

Expected results:
On similar setup on satellite 6.2, it takes under a minute

Steps to Reproduce (b):
1. systemctl restart foreman-tasks
2. watch /var/log/foreman/dynflow_executor.output for containing 'Everything ready for world'

Actual results:
It takes about 3.5 minutes to be ready

Expected results:
On similar setup on satellite 6.2, it takes under a minute

Additional info:

I've narrowed it down to /opt/rh/rh-ror42/root/usr/share/gems/gems/railties-4.2.6/lib/rails/application/routes_reloader.rb , that runs twice during the boot time and seems to cause the significant slow down at startup. It seems that
something changed between rails 4.1 and 4.2 to cause the delays.

The fix should make sure we don't start reloading the routes twice at the initialization, as that's what causes the long time to start.

Setting the severity on high, as it has impact not only on response times after the installation finishes, but also when the passenger scales up the processes.