304 should not generate an error level log

### Which service(blob, file, queue) does this issue concern?
blob

### Which version of the SDK was used? Please provide the output of `pip freeze`.

azure-common==1.1.16
azure-nspkg==3.0.2
azure-storage-blob==1.4.0
azure-storage-common==1.4.0
azure-storage-nspkg==3.1.0

### What problem was encountered?
I'm using the get_blob_to_text method using the `if_modified_since` arg.
Something like this `service.get_blob_to_text(container_name, path, if_modified_since=if_modified_since)`

The issue is that since the status code is often 304 (which is expected), the storageclient logs at Error level. The error is similar to this:
```ERROR [azure.storage.common.storageclient:429]: Client-Request-ID=0c308510-052f-11e9-ab74-6a0001d12220 Retry policy did not allow for a retry: Server-Timestamp=Fri, 21 Dec 2018 14:45:35 GMT, Server-Request-ID=e1c08360-d01e-0007-543b-996a67000000, HTTP status code=304, Exception=The condition specified using HTTP conditional header(s) is not met. ErrorCode: ConditionNotMet.```

I saw in the code that there is a list of expected errors. I think that a 304 should be expected when we have a conditional header.

### Have you found a mitigation/solution?
No

Note: for table service, please post the issue here instead: https://github.com/Azure/azure-cosmosdb-python.

Start with the storageclient retry and error-handling path used by get_blob_to_text, especially the list of expected errors mentioned in the issue. Check how a conditional request with HTTP status 304 is classified, and verify that an expected 304 no longer produces an error-level log.

Written by the indexing model from the issue text.