Put in a default hosted ES for tests

[pulkitsinghal]

Motivation: New folks should be able to easily use the example without setting up ES and tests would run against indices create/deleted/populated on that ES instance

1. Docker Script
2. Hosted
   1. https://app.bonsai.io/plans
   2. https://facetflow.com/#plans

[pulkitsinghal]

@harshadyeola would you like to take this on as an open-source contribution?

The idea is to get to a point where:

1. a Dockerfile and README instructions are added for other developers and contributors to start modifying this module very easily

2. the docker image may have two options to choose from for folder structure like:

   1. option a

      /volume/mounted/clone/of/loopback-connector-elastic-search
      /es/1.x/
      /es/2.x/
      /es/etc/

   2. option b

      /cloned/inside/image/loopback-connector-elastic-search
      /es/1.x/
      /es/2.x/
      /es/etc/

3. the developer can quickly test loopback-connector-elastic-search/examples against each locally hosted es version
   1. start docker image with cmd line arguments about which ES version to start by default on port 9300
   2. only one es version running at a time for simplicity and dev experimentation/testing/validation

Feel free to refine the ideas further,

[pulkitsinghal]

@raymondfeng and @bajtos and @doublemarked ... your comments and opinions on this would be invaluable to me as well.

[pulkitsinghal]

Leveraging other modules sounds nice:

1. https://elk-docker.readthedocs.io/#specific-version-combinations
   1. https://github.com/spujadas/elk-docker
2. https://github.com/deviantony/docker-elk

... but feels like overkill since Kibana and Logstash are unnecessary.

Maybe just referencing their dockerfiles to build our own would be enough?

[bajtos]

New folks should be able to easily use the example without setting up ES and tests would run against indices create/deleted/populated on that ES instance

In my personal experience, tests depending on database configuration maintained outside of the test suite are difficult to understand, as one has to switch often between the database setup and the test code.

Also because adding more fine-grained tables/indices to the database configuration is usually painful, people tend to reuse the same entities for multiple tests, occasionally adding more stuff to existing database entities, to the point where one cannot tell which part of the database setup is important for a test under examination and which part of the database setup is just junk required by other tests.

An example to illustrate my point, using a SQL database (sorry, I am not familiar with ES). Let's say we have a table "Product" with "id", "name" and "price". We write some tests to ensure the table can be queried and updated. Then we realise there is a bug in the way how date values are handled, so we add another column like "created". Rinse and repeat, and you end up with a table containing 10-20 columns, few indices and other stuff. A better approach is to have one specific table for each test (perhaps shared by a handful of related tests).

Having said that, this is my point of view that may not apply to your particular case, please do whatever works best for you!

[pulkitsinghal]

The DB/elasticsearch would exist only to verify connector compatibility. The setup of the table/collection/index would be all within the tests themselves.

[harshadyeola]

@pulkitsinghal I have sent an PR for testing the project with desired NODE and ES version. Please review and merge the PR.