they don't really belong into a new suite in test_execute

differently for the case where it is called in an already-invalidated state;
don't call upon self.connection

to it, so that we say we will do the wrapping just once right here
in _execute_context() / _execute_default().  An adjustment is made
to _handle_dbapi_error() to not assume self.__connection in case
we are already in an invalidated state

further adjustment to
0639c199a547343d62134d2f233225fd2862ec45, 41e7253dee168b8c26c49, #3266

_handle_dbapi_error(); these are now handled already and the reentrant
call is not needed / breaks things.  Adjustment to 41e7253dee168b8c26c49 /

take effect in all engine connection use cases, including
when user-custom connect routines are used via the
:paramref:`.create_engine.creator` parameter, as well as when
the :class:`.Connection` encounters a connection error on
revalidation.
fixes #3266

we will be able to parse dialect-specific arguments from string
configuration dictionaries.  Dialect classes can now provide their
own list of parameter types and string-conversion routines.
The feature is not yet used by the built-in dialects, however.
[ticket:2875]

of dbapi.Error (such as ``TypeError``, ``NotImplementedError``, etc.)
will propagate the exception unchanged.  Previously,
the error handling specific to the ``connect()`` routine would both
inappropriately run the exception through the dialect's
:meth:`.Dialect.is_disconnect` routine as well as wrap it in
a :class:`sqlalchemy.exc.DBAPIError`.  It is now propagated unchanged
in the same way as occurs within the execute process. [ticket:2881]
- add tests for this in test_parseconnect, but also add tests in test_execute
to ensure the execute() behavior as well

   "@", or "/" must be encoded." - so re-apply encoding to both password
and username, don't encode spaces as plus signs, don't encode any chars
outside of :, @, / on stringification - but we still parse for any
%XX character (is that right?)

:func:`.make_url` function **no longer URL encode the password**.
Database passwords that include characters like spaces, plus signs
and anything else should now represent these characters directly,
without any URL escaping. [ticket:2873]