Iterate on the payload generation for gSII.

[robshakir]

This PR makes an initial proposal for how the payload of gSII RPCs should look.

There are two cases that I think we need to consider:

• state that is part of an existing OpenConfig model
• protos that are generated for a subset of some other schema

For the OpenConfig case, ideally we would not generate new schemas, and be able to re-use existing schema components (and thus want to be able to write these components in YANG). This requires minor extension of the ygot toolchain to generate protobufs (see https://github.com/openconfig/ygot/compare/master...volatile where this change is made). The protos that are included herein use this approach.

The alternative is just to have hand-crafted protos as payload -- but this seems like it would be error prone in some cases.

The PR contains two generated protos:

• One that allows for interface admin status to be manipulated.
• A second that allows for QoS 1r2c policers to have their PIR manipulated.

[brianneville]

This change adds entries under volatile paths - can the motivation.md doc be updated to reflect this name if it has been finalized? right now the motivation.md doc makes references to dynamic paths, see: https://github.com/openconfig/gsii/blob/606a993/docs/motivation.md#data-modelling

[robshakir]

This change adds entries under volatile paths - can the motivation.md doc be updated to reflect this name if it has been finalized? right now the motivation.md doc makes references to dynamic paths, see: https://github.com/openconfig/gsii/blob/606a993/docs/motivation.md#data-modelling

Yes -- #1 covers this change within the motivation.md doc. I'll also put together a more succinct specification document once the design becomes more stable. I'm working on a reference implementation to make sure that we understand some of the nuances over at gSIIgo.