Adjust retryable settings for database errors

[neekolas]

I noticed that there were some types of StorageError that are currently treated as "not retryable" in libxmtp, but may occur randomly due to database load or even lock contention.

If one of those non-retryable errors was hit while processing a valid commit, the client would move on to the next commit and throw away the message leading to a fork.

This task would be to audit all of the storage-related errors and make sure that the retryability is correct, and then release it into a client SDK version that we can use to stress test forking with a real app like Convos.