Solr error should not be fatal

[jasonhildebrand]

This fixes a difficult usability issue if SOLR cannot be initialized.

Currently, a failure to initialize SOLR results in the container aborting. In my case, the solution required me to disable some conflicting SOLR request handlers via Drupal's UI, in order for Drupal to be able to generate config.zip. But this was impossible to do until I could get the container started. A difficult chicken-and-egg situation which is not easy to recover from.

I think it is better to flag the SOLR error clearly (hence this PR as well as Islandora-Devops/isle-buildkit#182) but allow the container to start so that Drupal is available.

This PR shows some earlier commits on my fork (but no diffs from them) because they were merged. Ugly, but I don't know how to clean this up short of deleting my fork entirely and re-creating. Maybe it's possible to squash when merging?

[DonRichards]

@jasonhildebrand Would you mind resolving the merge conflicts? I'll test it for you as soon as that's complete.

[jasonhildebrand]

Yes, I will try. I should have time in the next few days.

[jasonhildebrand]

@DonRichards sorry for the delay on this. I have rebased onto the current development branch and force-pushed. Ready for your testing.

[DonRichards]

How do I test this? I thought I would know but apparently not. I can get it to build but I can't seem to test a failure without it getting complicated quickly.

[jasonhildebrand]

In my islandora instance, I need to ensure that "request_handler_replicationslave_default_7_0_0" is disabled on the Request Handlers tab. If it is enabled, then "Get config.zip" fails with the message:

Some enabled parts of the configuration conflict with others:

    [Replication Slave](https://islandora.traefik.me/admin/config/search/search-api/server/default_solr_server/solr_request_handler)

So I can reproduce this issue simply by enabling the replicationslave handler, then restarting the drupal container