Avoid sending atomic update commands with null-documents

The DefaultIndexHandler handled this correctly, but the ATBlobFileIndexHandler and DexterityItemIndexHandler didn't.

In cases where attributes only consists of index names that don't correspond to a field in the Solr schema, we did end up in a situation where data was None, and was sent to Solr as the "document" in an atomic update command:

"add": {"doc": null}

This would Solr to respond with a 400, and reject the entire request which could contain other, valid updates.

Solr Response in the case of this error:

{  
   "responseHeader":{  
      "status":400,
      "QTime":57
   },
   "error":{  
      "msg":"Expected: OBJECT_START but got NULL at [1968]",
      "code":400,
      "metadata":[  
         "error-class",
         "org.apache.solr.common.SolrException",
         "root-error-class",
         "org.apache.solr.common.SolrException"
      ]
   }
}

Corresponding log entry:

2019-09-09 16:24:56.850 INFO  (qtp117009527-18) [   x:testserver] o.a.s.u.p.LogUpdateProcessorFactory [testserver]  webapp=/solr path=/update params={}{add=[createcontacts000000000000000001 (1644208163965108224), createcontacts000000000000000001 (1644208164015439872), createcontacts000000000000000001 (1644208164016488448)]} 0 55
2019-09-09 16:24:56.851 ERROR (qtp117009527-18) [   x:testserver] o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Expected: OBJECT_START but got NULL at [1968]
    <traceback>

4teamwork / ftw.solr

Avoid sending atomic update commands with null-documents #141