add atomic flag parsing semantics

[ElodinLaarz]

Explain how the atomic flag works and interacts with oc-ext:atomic extension.

Copilot Summary:

This pull request updates the gnmi-specification.md to clarify and formalize the parsing and behavioral semantics of atomic notifications in the gNMI protocol. The most significant changes include a new section detailing how to parse atomic notifications, guidance for both clients and devices on handling atomic containers in subscriptions, and an update to the revision history to document these changes.

Atomic Notification Parsing and Behavior:

• Added a new section, "Parsing Atomic gNMI Notifications," which details how the atomic flag in a Notification message should be interpreted, emphasizing schema-independence, implicit deletion of prior state, invalidation rules, and the importance of prefix scope.
• Clarified that the atomic field in the Notification message indicates an atomic update, and explained how atomic and non-atomic notifications affect the validity of cached state for a given prefix.

Atomic Containers in Subscriptions and Requests:

• Added a section on "Atomic Containers in Subscribe and Get Requests," explaining how devices should generate atomic notifications when clients subscribe to only a subset of leaves within an atomic container, and how clients should interpret such notifications.

Documentation and Navigation Updates:

• Updated the table of contents to include new sections for parsing atomic notifications and atomic containers in subscriptions/requests. [1] [2]
• Updated the revision history to version 0.11.0, documenting the new definitions for parsing semantics of the atomic flag.

[romeyod]

should we add some guidance about how atomic containers should ideally not have frequently changing leafs/containers like counters?

[romeyod]

Can we also add some documentation about only delete notifications dont need atomic flag set as such notifications with Prefix are atomic (i.e. Delete the entire subtree)

[dplore]

Add a more simple example, ie:

prefix a/b
update: c/d
update: c/e
time: 1

prefix a/b
update: c/e
time: 2

Result is "a/b/c/d" is deleted.

[dplore]

Let's say something like:
For OpenConfig data models, this behavior is not allowed. If a path is marked atomic in OpenConfig data models, the server must always send atomic updates. However, since gnmi is schema agnostic, this behavior might be useful for other schemas.

[dplore]

Seems like we might need an example added after this one where a subcontainer is updated with atomic true. ie:

Prefix: a/b
Update: c/d
atomic: True
time: 124

Expected client behavior is this would invalidate the notification at time:123

[dplore]

Add option that server may return a gRPC error if a subscription to a sub container is not supported.