Sometimes FTS can return an empty error block in the HTTP response

Not too sure what's causing this and it's intermittent, but I've included a few steps to (hopefully) reproduce the issue.

Expected Behavior
If there are no errors with the FTS query, it should not return an "errors" field in its status

Actual Behavior
Sometimes FTS will return an empty errors block in the status field, leading some clients to believe that an error has occurred:

$ curl -sS -u Administrator:password -XPOST -H "Content-Type: application/json" \

http://10.142.191.102:8094/api/index/test/query \

-d '{

  "explain": true,

  "fields": [

    "*"

  ],

  "highlight": {},

  "query": {

    "query": "manchester"

  }

}' | jq '.status'

{

  "total": 6,

  "failed": 0,

  "successful": 6,

  "errors": {}

}

Steps to Reproduce

1. Create a cluster with multiple FTS nodes (my tests used 3), I have not been able to reproduce this issue with just a single FTS node.
2. Load the travel-sample bucket onto this cluster.
3. Create an FTS index on this bucket, for convenience I just used the default one that the UI generates, in my test it was called 'test'.
4. Query the index many times using the REST API and verify the 'status' block of the response. In my test, I created a file 'fts_test.sh' which included the following:

   curl -sS -u Administrator:password -XPOST -H "Content-Type: application/json" \

   http://<ip>:8094/api/index/test/query \

   -d '{

   "explain": true,

   "fields": [

   "*"

   ],

   "highlight": {},

   "query": {

   "query": "manchester"

   }

   }' | jq '.status.errors' | grep -v 'null'

   Then run this script many times:

   for i in $(seq 1 100000); do bash test.sh; done

5. If you see the output '{}' from the script, then it means that it has found an error block which is present, but an empty object. From my testing, with 100000 queries, it returned approximately 10 empty error blocks, so this does not happen often.

I set this as 'minor' because functionally it's not a big deal, but some applications expect this field to exist only if there are errors with the query.
It would be better to maintain this behavior or to always return the error block, even if it is empty.