Tomcat starts too slow sometimes due to RepositoryServlet init process. Initialize it asynchronously.

If lucene index needs to be recreated or if a cluster node is a bit behind the current revision number on startup, then it causes tomcat server to start too slowly.
This might be not a big problem in most cases.
However, when a customer has an additional web application for something else together with cms.war and site.war (e.g, ElasticSearch or Solr webapp or another (REST) web application based on the ElasticSearch or something else), they want to be able to use those extra web application as soon as possible, regardless of the initialization progress of the repository (in cms.war mostly).
It would be nice if the RepositoryServlet starts up quickly regardless of its real initialization detail steps to make the Tomcat container available as soon as possible.

To achieve this, I think RepositoryServlet could have initialized itself asynchronously in a separate thread, like org.hippoecm.hst.site.container.HstContextLoaderListener does. By its asynchronous initialization, the site.war starts up very quickly all the time.

Someone may have a concern that the cms.war should be available only after the repository completes its initialization and the JCR repository is really ready to serve.
However, this concern is not a big issue, IMHO.
Here's the reason:

The current initialization steps of RepositoryServlet are as follows roughly:

• Register HippoEventBus service
• Register AuditLogger service
• Setting repository related system properties
• Create and register repository instance
• LocalHippoRepository is created
  . bootstrapping
  . initialize system nodes
  . initializing daemon modules
  . configure security manager
• Register vm:// repository.

Please note that the final step, "Register vm:// repository", really make the repository ready to serve to the clients.

Therefore, all the initialization steps can be done in a separate thread.
During this initialization steps, the repository is simply not available, which leads HST to wait until the repository is ready (already existing feature because it's loaded in parallel from site.war anyway), and CMS UI application simply not available, which is fine as long as it logs an error about the repository is not available through vm:// for instance.

There might be another concern like 'Oh, we need to check the server live status by checking the port number 8080, the tomcat's port, so it could be better to wait until repository is really available.'
Well, that's not really reflecting the real use cases at all. In practice, people normally checks the ping URL such as /cms/ping or /site/ping for the server live status checking. And the ping servlets always check the repository's availability by trying to access vm:// repository anyway.

Therefore, by improving the RepositoryServlet to initialize itself asynchronously, I don't see any side effects at all.

So, why don't we improve it to help out the situation I mentioned above.