Update CT primitive batch_id plan modifiers

[chrismarget-j]

The batch_id attribute represents the ID of the "batch" policy object associated with a Connectivity Template primitive.

Primitives which have children keep their child IDs in the "batch" policy object.

Primitives which do not have children do not have a "batch" policy object.

So, the state (null or not) of batch_id of a given primitive depends on whether that primitive has any child primitives.

Each primitive has a plan modifier which detected deletion of the last child, and set the batch_id from some value to null.

The original description is accurate: "preserves the the state value unless all child primitives have been removed, in which case null is planned"

The problem is we're only detecting the transition from value -> null. We don't detect the other side of it: Creation of the first child, in which case the batch_id needs to be updated from null to some known value.

This PR modifies the string plan modification logic of each child-capable primitive to ensure they handle switching between known and null and back again.

• IpLink
• BgpPeeringGenericSystem
• BgpPeeringIpEndpoint
• DynamicBgpPeering
• VirtualNetworkSingle

[coterv]

Hi,

Still facing the same issue described in #1012 in v0.79.1:

│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for module.blueprints.apstra_datacenter_connectivity_template_interface.ct_interface["MAIN_ALC1.IxC-FW_SRX"] to include new values learned so far during apply, provider "registry.terraform.io/juniper/apstra" produced an invalid new value for
│ .ip_links["ip_link_I-MANO"].batch_id: was null, but now cty.UnknownVal(cty.String).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Thanks in advance!

[coterv]

Issue resolved in v0.80.1