jnote and wnote should not raise errors when connected to legacy servers

When connected to a legacy (pre-2.6) version of MongoDB, the Bulk API will raise OperationFailure if the server response includes a jnote or wnote field. This was done to mimic the error a 2.6 standalone returns if a write concern with w > 1 is used or a mongo cluster returns if j=True is used with journaling disabled.

Unfortunately, the server will also return wnote if the write concern was not satisfied because no write operations were performed (e.g. an update or remove operation that didn't match any documents).

>>> bulk = c.foo.bar.initialize_ordered_bulk_op()

>>> bulk.find({"something": "that doesn't exist"}).remove()

>>> bulk.execute({'w': 2})

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "pymongo/bulk.py", line 585, in execute

    return self.__bulk.execute(write_concern)

  File "pymongo/bulk.py", line 433, in execute

    return self.execute_legacy(generator, write_concern)

  File "pymongo/bulk.py", line 394, in execute_legacy

    _merge_legacy(run, full_result, exc.details, idx)

  File "pymongo/bulk.py", line 93, in _merge_legacy

    raise OperationFailure(note, _BAD_VALUE, result)

pymongo.errors.OperationFailure: no write has been done on this connection

>>> c.server_info()['version']

u'2.4.10'

The impact of this bug should be limited by a few factors:

• This error is only raised by the Bulk API, not collection.insert/update/remove
• In PyMongo the execute method has to be called with a custom write concern with w > 1. No error is raised when using the default write acknowledgement or w=1.
• The bug only manifests with server versions before 2.6. The bulk API is only really useful from a performance perspective when connected to MongoDB 2.6 or newer.