Breaking Change: update model.py classes to use proto-plus instead of _pb

[tswast]

Currently the classes in model.py use the underlying protobuf _pb object for read-only properties instead of the proto-plus object.

python-bigquery/google/cloud/bigquery/model.py

Line 58 in b8f502b

self._proto = types.Model()._pb

This avoided some possible breaking changes, but was mostly done to expedite the transition to the microgenerator.

There are some benefits to using proto-plus that would be worth taking advantage of. Most importantly, timestamp well-known types are properly translated into a datetime-like object with proto-plus.

Why now?

There are some breaking changes in the latest generated clients due to googleapis/gapic-generator-python#595

• https://github.com/googleapis/python-bigquery/pull/316/files#diff-daa390c4795c10c42d5e8cec48f5339c

If we need to make a breaking change for these changes, we might as well update the classes to support the latest versions.

[cguardia]

@tswast After getting a bit more work done here, I saw that routine also uses _pb, so I started to look at getting rid of it there too:

https://github.com/googleapis/python-bigquery/blob/master/google/cloud/bigquery/routine.py#L202

When the line above runs, resource is equal to {'typeKind': 'INT64'}. If I replace that line with e.g. resource = type(value).to_dict(value), resource is {'type_kind': 2}.

This is an example of the kind of under the hood name and type conversion that json_format does. There are more than a few tests that take this for granted, not only in model code, but also in client code. The problem is that some actual code outside of the tests also relies on this on occasion, so when I tried my initial approach to change to snake_case wholesale, I sometimes ended up with half a dozen more failing tests after making a change to correct the case of a single different test.

I'm working on this still, but I wanted to describe this issue that has complicated the work a bit.

[tswast]

Alternatively, we could switch to returning dictionaries for these BigQuery ML classes. The proto definitions aren't republished as often as I first anticipated, as it's a manual process.

[tswast]

Dictionaries would be a worse experience from an IDE and docs perspective, though.

[tswast]

Closing in favor of #814