Currently, we have two versions of ClientOptions::parse: one asynchronous (which is only available when neither the sync nor tokio-sync feature is enabled) and synchronous (which is only available when either the sync or tokio-sync feature is enabled).

Now that RUST-488 allows using both the sync and async APIs at once, this is a funny restriction, because it means you can only use the sync version of parse if you are using both APIs together.

The new ConnectionString API provides a workaround for this since ClientOptions::parse_connection_string is available regardless of if either of the sync features are on, but it seems like we should permit something similar with the parse methods accepting a string.

We unfortunately can't just remove the conditional definition from either method because they then conflict with each other, but we should think about what we want the APIs for this to eventually look like in our next major release and see if we can start to move in that direction.