Update grpc, protobuf, datastore and gax dependencies, regenerate SPI classes

[garrettjonesgoogle]

• Updating grpc to 1.0.1 and protobuf to 3.0.0
• Converting PageAccessor to PagedListResponse
• Adding auto-generated tests for logging

[mziccard]

@garrettjonesgoogle I finally merged monitoring, does this affect this PR?

Build is failing, it seems that gax 0.0.18 is not out yet.

[garrettjonesgoogle]

Yes, monitoring affects this PR. I will update it. gax 0.0.18 is released now so the next build should succeed.

[garrettjonesgoogle]

Updated monitoring, PTAL

[garrettjonesgoogle]

It turns out that datastore depended on generated proto stuff too, so I have updated the dependency. PTAL.

[coveralls]

Coverage increased (+0.1%) to 84.749% when pulling bc9a6c4 on garrettjonesgoogle:master into 062600a on GoogleCloudPlatform:master.

[mziccard]

It turns out that datastore depended on generated proto stuff too, so I have updated the dependency. PTAL.

Yes this was discussed here.

Non related to this PR: I noticed that in all VeneerToolkit pom.xml there's the auto-value dependency, is it really needed?

<dependency>
  <groupId>com.google.auto.value</groupId>
  <artifactId>auto-value</artifactId>
  <version>1.1</version>
</dependency>

[garrettjonesgoogle]

It looks like it wasn't needed; it got added once, and then stayed for the ride. I have removed it now.

[coveralls]

Coverage increased (+0.1%) to 84.744% when pulling bb52fa0 on garrettjonesgoogle:master into 947f03e on GoogleCloudPlatform:master.

[garrettjonesgoogle]

I think this is ready to merge - all tests pass.

[mziccard]

Was the latest merge commit necessary (bb52fa0)?

I have a bunch of PRs to merge, this will be the next one.

[garrettjonesgoogle]

It was not strictly necessary; I was just making sure this PR was up to date. Does it cause a problem?

[mziccard]

It was not strictly necessary; I was just making sure this PR was up to date. Does it cause a problem?

I would not say it causes problems but if I merge this PR using a merge commit that merge commit will remain in the history of master and its unnecessary, if I squash the commits in this PR I get rid of that commit but I also lose the history (which I would prefer not to).

[garrettjonesgoogle]

I see. For googleapis/, we have been doing squash commits to master in order to have a more concise history instead of including every update in each PR, so this merge was more appropriate for that model. I could rebase and force push to the PR so that the merge disappears, if you would like (just let me know).

[mziccard]

I see now that all major changes are in one commit (the first one). I'll squash commits as history is not so meaningful. In cases like this, however, where we updated many different and unrelated dependencies as well as added tests, I prefer having different commits and keep them in the history. So in case something went wrong you can revert changes at a finer granularity.

[mziccard]

I am adding the don't merge label as this PR causes all gRPC calls to fail with a DEADLINE_EXCEEDED error.

[garrettjonesgoogle]

I have fixed the gRPC call failures. PTAL.

[garrettjonesgoogle]

Do I need to worry about the appveyor failure?

[coveralls]

Coverage increased (+0.2%) to 84.807% when pulling a39c658 on garrettjonesgoogle:master into 947f03e on GoogleCloudPlatform:master.