Retry decorator on RateLimitExceeded issue

## Summary

Enabling retry logic does not work for rate limit exceeded responses.

## Detailed Information

retry decorator expects a `RateLimitExceeded` error to be raised, though `session.request` method does not raise an exception if a response is returned by the server no matter the status code.

I've tested it on azure_arm driver by setting `RETRY_FAILED_HTTP_REQUESTS` to True and trying:
```python
while True:
nodes = driver.list_nodes()
print(nodes)
```

Hitting the throttling limit results in:

```python
Traceback (most recent call last):
File "test.py", line 23, in
nodes = driver.list_nodes()
File "/home/dimgal/libcloud/libcloud/compute/drivers/azure_arm.py", line 395, in list_nodes
r = self.connection.request(action,
File "/home/dimgal/libcloud/libcloud/common/azure_arm.py", line 227, in request
return super(AzureResourceManagementConnection, self) \
File "/home/dimgal/libcloud/libcloud/common/base.py", line 655, in request
response = responseCls(**kwargs)
File "/home/dimgal/libcloud/libcloud/common/base.py", line 165, in __init__
raise exception_from_message(code=self.status,
libcloud.common.exceptions.RateLimitReachedError: 429 Rate limit exceeded
```
urllib3 supports [retries](https://urllib3.readthedocs.io/en/latest/reference/urllib3.util.html#urllib3.util.Retry) based on HTTP status codes, maybe use this? Let me know how you think this should be handled

Start by tracing the retry decorator and the request flow in libcloud/common/base.py, then compare the Azure ARM path in libcloud/common/azure_arm.py with the azure_arm driver call shown in the report. Reproduce the configured rate-limit case and determine how a returned 429 becomes RateLimitReachedError. Done means retry behavior works for rate-limit responses when retry logic is enabled.

Written by the indexing model from the issue text.