fix: Introspect to get column types in cursor.execute

[c24t]

Addresses googleapis/python-spanner-django#566.

This PR adds an extra call to get the table's schema before making inserts from cursor.execute. Spanner requires us to
pass parameter types to Transaction.execute_update, before this change we inferred the Spanner column types from the native python types in the prepared statement. Besides being a hack, this meant we couldn't handle inserts with null values. See googleapis/python-spanner-django#566 for more detail.

This change fixes many django test failures, notably the modeladmin and (most of) expressions_case tests, which all failed with InvalidArgument('Unable to infer type for parameter ....') before.

Note that Connection.run_statement still calls _execute_insert_heterogenous without param_types, and this still results in a call to get_param_types. I didn't replace this because it didn't affect the django tests I was running. If we pursue this change we should remove get_param_types altogether next.

There may be other problems with this approach that don't show up in the tests. For example, this change assumes the schema doesn't change between reading INFORMATION_SCHEMA.COLUMNS and doing the insert. Doing an extra read op before each insert may also slow the client down.

[c24t]

Note that Connection.run_statement still calls _execute_insert_heterogenous without param_types, and this still results in a call to get_param_types.

Running more of the django tests, it looks like this is responsible for another error:

TypeError: Parameter to MergeFrom() must be instance of same class: expected google.spanner.v1.Type got NoneType.

This shows up in model_inheritance among other tests.

[olavloite]

I would strongly recommend that you only do this as a workaround when running against the emulator, as real Spanner seems to accept the parameter type to be missing. Otherwise you will be slowing down statements unnecessarily in production environments.
Furthermore, you probably need to do this for all types of statements on the emulator, not only insert statements.

[IlyaFaer]

I suppose this PR can be closed. It adds some redundant code, which will be in production, but will work only for emulator cases. On SQLAlchemy we've just skipped the tests, which are not working on emulator, like this:
https://github.com/googleapis/python-spanner-sqlalchemy/blob/e97325de221d201a306ba92fecf8afc9856fa2c5/test/test_suite_13.py#L343-L345

I think let's do the same for Django. @olavloite, @larkee, what do you say?

[olavloite]

I suppose this PR can be closed. It adds some redundant code, which will be in production, but will work only for emulator cases. On SQLAlchemy we've just skipped the tests, which are not working on emulator, like this: https://github.com/googleapis/python-spanner-sqlalchemy/blob/e97325de221d201a306ba92fecf8afc9856fa2c5/test/test_suite_13.py#L343-L345

I think let's do the same for Django. @olavloite, @larkee, what do you say?

Yes, this PR is more than a year old, and I would have serious doubts about the performance impacts of this. In addition, real Spanner supports non-typed parameters, and the missing support for non-typed parameters for some type (DATE and TIMESTAMP) in the emulator is considered a bug: GoogleCloudPlatform/cloud-spanner-emulator#31