Update error messages for timeout errors

[SamRemis]

Description

This PR improves timeout error messages to provide more actionable information for debugging. Currently, timeout errors sometimes display messages like "Client timeout occurred: " with no additional context. This occurs when the error's string representation is an empty string.

For the CRT client, we updated _CRTTimeoutError to include the underlying AWS error name and message, changing errors from Client timeout occurred: to CRT AWS_IO_SOCKET_TIMEOUT: socket operation timed out.

For all clients, we now default to using the exception's class name when the string representation is empty. This can occur in aiohttp when the total attribute is set on the ClientTimeout class, which will raise a TimeoutError with no additional info. This updates the same blank error message to A timeout error occurred..

Test file:
timeout_exceptions_test.py

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[SamRemis]

Setting back to draft mode for now; I wanted to get this out there to confirm everyone is good with the two-pronged approach of both updating our CRT errors and having a default.

I think the exception message should ultimately be something along the lines of ""Client timeout occurred: {error_msg}, please see underlying exception for more details.", but wanted to get team input on final messaging.

[nateprewitt]

This seems like we're leaking a detail somewhere. Is this something coming from the CRT that's requiring us to pull the __name__ off the error?

[SamRemis]

This is more meant to target cases like aiohttp's total_timeout which only raises an empty asyncio.TimeoutError with no other context. I put a link to an example of this in the PR's description. It's just a way for us to make sure there's some string representation in an error where the string representation of it is otherwise empty.

Example from a Python REPL:

>>> str(TimeoutError())
''

[nateprewitt]

from should give us the context (and the originating error). If they don't include anything, that's fine. By creating the chain, we can look to see what happened. Including {e} in the message to begin with is likely not necessary. That's an artifact of a time before we had better tracebacks.

[nateprewitt]

A timeout error occurred. is probably sufficient in this case.

[nateprewitt]

Ideally, we should be keeping the context with the from but we can include the message to make the immediate information clearer.