Restore support for Elasticsearch

[nsoft]

Would like to have a built in sender for this, but I've had to remove it because I can't afford the time to chase down the stuff they keep breaking (see #123) I'll leave the existing classes in place for a while incase someone wants to pick this up.

[mbiasutto]

Hi @nsoft, how can I help with this? I feel, fixing this issue might be a good start, what do you think ?

[nsoft]

Although marked help wanted, and help is definitely welcome, this is a difficult first issue unless you are already an expert with Elasticsearch, know what Randomized Testing is all about and just love to pick apart conflicting dependencies :). Issues like this might motivate a more rigidly containerized direction such as OSGI or perhaps a scheme for loading either projects or steps with their own class loaders or the like...

[nsoft]

Just to add a little detail for whenever I look back at this the issue here is that elasticsearch chose to reference test infrastructure classes in their production code (here: https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/common/Randomness.java#L55) which seems like stunningly bad practice to me but it's their project. The result is as soon as you add a dependency to lucene-solr test classes you inherit the randomized testing jar on your classpath and any and (probably all) of you elastic related unit tests go belly up even if you never intended to use any of the randomized testing stuff at all. The Solr tests don't depend on or require randomized testing, but it's a dependency at the build file level... This particular problem MIGHT be resolvable by fiddling with dependencies in Gradle, but given Elastic's back compatibility record, and the fact they are now on 7.x I expect other stuff to crop up. Also, even if solved with gradle this is a ticking timebomb for anyone using our project with elastic who might inadvertently get a com.carrotsearch.randomizedtesting.RandomizedContext class into their classpath... Also need to consider that exclusions at the gradle level must translate into the published pom.xml for our project, or if we become another source of "elastic tests go boom" as soon as we're added as a dependency.