numerous unit test failures after elasticsearch upgrade to 0.90.6

[mrvisser]

After upgrading elasticsearch to 0.90.6 the tests take ~23 minutes to complete and I've seen anywhere between 4 to 30 test failures, usually starting with search failures followed by timeout failures. Elasticsearch 0.90.1 and 0.90.5 both work fine.

[nicolaasmatthijs]

Assigning to @simong for investigation

[stuartf]

This might just be an issue with elasticsearch 0.90.6 my logs show running out of java heap space which could be elastic/elasticsearch#4093

[stuartf]

After upgrading to elasticsearch 0.90.7 I'm still seeing ~22 failures but they're looking more consistent and no memory errors in the logs. So now I think we might be hitting this one: elastic/elasticsearch#3849

[stuartf]

I just ran a git bisect on elasticsearch to track down the commit that breaks our tests, here's the result:

39dafc064865a624f93ea1bb8f05cc6a730bc3ac is the first bad commit
commit 39dafc064865a624f93ea1bb8f05cc6a730bc3ac
Author: Martijn van Groningen <martijn.v.groningen@gmail.com>
Date:   Mon Oct 14 15:31:57 2013 +0200

    Prohibit indexing a document with parent for a type that doesn't have a `_parent` field configured and prohibit adding a _parent field to an existing mapping.

    Closes #3848
    Closes #3849

:040000 040000 f3327ab00149cf6f7bd2a100099cbb33135582ce f73b356613f5ed4dea2e5e1e2ac950fb86cf41c9 M  src
bisect run success

[mrvisser]

It appears we apply a "_parent": undefined to all our documents, even non-child documents. There was an error seen within the trace logging that points this out. The solution is to conditionally add the _parent key only if specified on the document being indexed. I've submit a fix.

[mrvisser]

Leaving assigned to @stuartf for review.

[mrvisser]

This also improves the search logging so that an error will be logged if ES returns such an error.

[stuartf]

reviewed, verified, merged

[mrvisser]

Note that ElasticSearch 0.20.6 (and potentially all 0.20.x) has an issue where it will throw an error if you add an "ids" filter that has 0 items. This causes a failure in the unit tests, and in production you can see the effect by:

1. Visit a user's content library that has 0 items
2. Try and use the library search

You would expect simply 0 items, however there is a 500 error behind the scenes. This only impacts libraries w/ 0 items. This exists before and after this PR, but upgrading ES will resolve the issue.