User-defined defaults and description updates for list keys

[earies]

• (M) release/models/network-instance/openconfig-network-instance-l2.yang
• (M) release/models/network-instance/openconfig-network-instance.yang
  • Update network-instance name description to provide implementation
    guidance on default name for DEFAULT_INSTANCE should OpenConfig
    schemas not be used for configuration but rather for state only as
    well as suggested name
  • Update protocol instance name with suggested value as well as
    default name should OpenConfig schemas not be used for
    configuration but rather for state only
• (M) release/models/system/openconfig-system-grpc.yang
  • Update grpc server name with suggested value as well as default
    name should OpenConfig schemas not be used for configuration but
    rather for state only

This PR is to kick off the concept of embedding implementation suggestions (and
defaults where applicable) for where user-defined fields are used as list keys.
Most notably starting in areas where users have a hard time selecting an
appropriate value and where an implementation may only support single instances
in a multi-instance capable model structure.

The notion of implementation guidance and default values also caters to
scenarios where a client may want to consume OpenConfig modeled state data
without using OpenConfig modeled configuration. These suggestions and defaults
enable the implementation to pack known values into list keys to formulate
compliant paths.

[OpenConfigBot]

Compatibility Report for commit 5154323:
⛔ yanglint@SO 1.10.17

[robshakir]

Thanks for suggesting this Ebben, I definitely think its worth discussing.

One area that I think we probably should discuss is the relationship between some of these defaults and the config used at boot time. There is an implication in some of the comments that some of these values are mutable post-initialisation, which I think has some implementation implications that we might want to consider.

I'm fine, in general, though with an approach that says "an implementor is recommended to use this name as a default value".

[dplore]

This was discussed with the operators group today. Feedback was we should make this a major revision and point out in this PR that this is may be a backwards incompatible change for some implementations due to what could be a NEW default value of a network instance name (for example if a vendor currently has some default name string such as "BASE" and this change requires “DEFAULT”

[earies]

Thx @dplore - sounds reasonable to me. Will update the version and revision descriptions to reflect this across the models