Remove id from Session message

[ccifra]

What does this Pull Request accomplish?

• Having both name and id is somewhat confusing
• It makes using the session in interactive tools like bloom RPC difficult, since oneof is a little complex to use.

I don't think ID should ever be used. There are a lot of advantages to keeping the data on the wire "time invariant" or independent on server state. For example, we are trying to do batching to improve throughput when doing "cloud-based measurements" as part of various LTIs and hopefully products.

Even if we remove id we can still maintain the current behavior by generating a name if the client does not specify. Clients who use name should not need to make any changes to their code. The wire format does not break for clients who use name, so we don't even need to require clients change. The wire format does not really break for clients that use id since they can't set it and our server will stop setting it. Clients who use id should be treating Session as an opaque structure since there is nothing they can do with name.

Why should this Pull Request be merged?

General improvement to grpc-device.

What testing has been done?

Existing test suite updated.

[ccifra]

Ready for review.

[astarche]

It looks (to me) like all of the examples are OK. Either way, there should be a release task to run all the examples, especially with some major changes this release. This is something that mypy should catch, so another case for expanding which drivers pass mypy so we can validate_examples on them on the CI.

Nothing needed for this PR. @reckenro can you see if there's a good place to track that release task?

[reckenro]

It looks (to me) like all of the examples are OK. Either way, there should be a release task to run all the examples, especially with some major changes this release. This is something that mypy should catch, so another case for expanding which drivers pass mypy so we can validate_examples on them on the CI.

Nothing needed for this PR. @reckenro can you see if there's a good place to track that release task?

Yeah, I'm starting an email thread with our PO (Harsha) for where to track this among other tasks with the next release. I'm guessing it'll become a sustaining item in our backlog but whatever the case I'll capture this along with that Release related work.