Integrate EffectiveAugmentationSchema into AugmentationSchemaNode/AugmentEffectiveStatement}
Description
As part of initial NormalizedNode integration and then when we fixed , we have noted an omission on yang.model.api projection.
The problem is that AugmentationSchemaNode.getChildren() reflects its child statements as declared in source, without taking into account further augmentations at target instantiation site.
The differences are rather under-documented and at its core demonstrates there is a significant 'point of view' difference as to what it 'effective children' means:
in binding, we need to see how augment children were effectively declared
in yang.model.api, we would like to project them as replicas of how those statements look at instantiation site
in yang.data.api we care about the former due to AugmentationNode, which is a leak (through the datastore operations logic) from binding and we aim to remove this with
Introduce an additional methods to expose the equivalent of EffectiveAugmentationSchema from both AugmentationSchemaNode and AugmentEffectiveStatement
which will allow users to flip between the two views.
With AugmentationNode gone from yang-data-api, there is very little incentive to actually provide this view, as there really are no more users left. EffectiveAugmentationSchema ends up being deprecated for removal.
As part of initial NormalizedNode integration and then when we fixed , we have noted an omission on yang.model.api projection.
The problem is that AugmentationSchemaNode.getChildren() reflects its child statements as declared in source, without taking into account further augmentations at target instantiation site.
We have solved this with AugmentationSchemaProxy and then supplanted it with EffectiveAugmentationSchema.
The differences are rather under-documented and at its core demonstrates there is a significant 'point of view' difference as to what it 'effective children' means:
in binding, we need to see how augment children were effectively declared
in yang.model.api, we would like to project them as replicas of how those statements look at instantiation site
in yang.data.api we care about the former due to AugmentationNode, which is a leak (through the datastore operations logic) from binding and we aim to remove this with
Introduce an additional methods to expose the equivalent of EffectiveAugmentationSchema from both AugmentationSchemaNode and AugmentEffectiveStatement
which will allow users to flip between the two views.