feat(spanner/spansql): add support for protobuf column types & Proto bundles

[dfinkel]

feat(spansql): CREATE/ALTER/DROP PROTO BUNDLE

Add support for parsing and serializing CREATE, ALTER and DROP PROTO
BUNDLE DDL statements.

feat(spanner/spansql): support for protobuf types

Now that Spanner supports protobuf message and enum-typed columns and
casts, add support for parsing those those types.

Since protobuf columns aren't distinguished by a keyword, adjust the
parser to see any unquoted identifier that's not a known type as a
possible protobuf type and loop, consuming .s and identifiers until it
hits a non-ident/. token. (to match the proto namespace components up
through the message or enum names)

To track the fully-qualified message/enum type-name add an additional
field to the Type struct (tentatively) called ProtoRef so we can
recover the message/enum name if canonicalizing everything.

closes: #10944

[rahul2393]

@dfinkel tests failed, please check and fix them

[dfinkel]

Thanks @rahul2393 for the prompt review and approval!

Sorry about the test failures!
It looks like an else if block got lost while I was cleaning up the commits before sending it out for review. (then I absentmindedly ran the tests for the wrong directory 🫤 )

The tests for this package now pass locally.

[dfinkel]

Friendly ping @rahul2393

(thanks for the prompt approval)

[dfinkel]

@rahul2393 if you have a few minutes, can you make another pass over this PR?

[dfinkel]

Thanks @rahul2393 !

[apstndb]

I believe they are not a valid GoogleSQL query because ENUM and PROTO is keywords.

$ gcloud spanner databases execute-sql ${SPANNER_DATABASE} --sql 'SELECT CAST(Bar AS PROTO)'
ERROR: (gcloud.spanner.databases.execute-sql) INVALID_ARGUMENT: Syntax error: Unexpected keyword PROTO [at 1:20]\nSELECT CAST(Bar AS PROTO)\n                   ^
- '@type': type.googleapis.com/google.rpc.LocalizedMessage
  locale: en-US
  message: |-
    Syntax error: Unexpected keyword PROTO [at 1:20]
    SELECT CAST(Bar AS PROTO)
                       ^

$ gcloud spanner databases execute-sql ${SPANNER_DATABASE} --sql 'SELECT CAST(Bar AS ENUM)'                  
ERROR: (gcloud.spanner.databases.execute-sql) INVALID_ARGUMENT: Syntax error: Unexpected keyword ENUM [at 1:20]\nSELECT CAST(Bar AS ENUM)\n                   ^
- '@type': type.googleapis.com/google.rpc.LocalizedMessage
  locale: en-US
  message: |-
    Syntax error: Unexpected keyword ENUM [at 1:20]
    SELECT CAST(Bar AS ENUM)
                       ^

CAST AS ENUM and CAST AS PROTO needs named type name of PROTO or ENUM, not PROTO or ENUM keywords.

https://cloud.google.com/spanner/docs/reference/standard-sql/data-types#enum_type

You reference an enum type, such as when using CAST, by using its fully qualified name.

https://cloud.google.com/spanner/docs/reference/standard-sql/conversion_functions#cast_as_proto

SELECT
  CAST(
    '''
    year: 2001
    month: 9
    type { award_name: 'Best Artist' category: 'Artist' }
    type { award_name: 'Best Album' category: 'Album' }
    '''
    AS googlesql.examples.music.Award)
  AS award_col

Therefore, they should be escaped named type name:

CAST(Bar AS `PROTO`)
CAST(Bar AS `ENUM`)

or other named type names.

CAST(Bar AS ProtoType)
CAST(Bar AS EnumType)

[apstndb]

Same

$ gcloud spanner databases execute-sql ${SPANNER_DATABASE} --sql 'SELECT CAST(7 AS ENUM)'  
ERROR: (gcloud.spanner.databases.execute-sql) INVALID_ARGUMENT: Syntax error: Unexpected keyword ENUM [at 1:18]\nSELECT CAST(7 AS ENUM)\n                 ^
- '@type': type.googleapis.com/google.rpc.LocalizedMessage
  locale: en-US
  message: |-
    Syntax error: Unexpected keyword ENUM [at 1:18]
    SELECT CAST(7 AS ENUM)
                     ^

[apstndb]

I have re-used this tests for another purpose( cloudspannerecosystem/memefish#115 ) , so it is better to contain only valid cases.
Would you fix it? @dfinkel
If not, I will send PR.

[dfinkel]

Thanks @apstndb, I definitely copied those cases from the documentation. I can put together a PR to switch those to something that's actually valid tomorrow.

(I think I meant to verify that those were valid before sending this PR out but as usual other things intervened and that got lost)

[dfinkel]

I just opened a PR with fixes for some bugs I ran into while using the features in this PR (including fixing the tests that @apstndb pointed out):
#11279

The most problematic bug is the fact that NOT NULL protobuf-typed columns don't get parsed correctly because I had accidentally made the parser too greedy.

Thanks in advance!