**Breaking Change** eliminate resource pool utilization attributes from resource pool resources

[chrismarget-j]

This PR forces to null all resource pool utilization/status attributes in the following Terraform resources:

• apstra_asn_pool
• apstra_integer_pool
• apstra_ipv4_pool
• apstra_ipv6_pool
• apstra_vni_pool

Those attributes are:

• status
• total
• used
• used_percentage

The attributes still exist, but are set to null in the various Terraform resources. They're available and populated correctly in the complementary Terraform data sources.

Why?

• Collecting this (possibly not interesting) data takes time - why ask for something if nobody looks at it?
• Under heavy load the Apstra API doesn't always return the complete pool info immediately after creation, leaving us with incomplete information.
• Something seems to have changed between terraform-plugin-framework 1.5.0 and 1.9.0. This has led to awkwardness with object sets where individual objects have unknown elements (our situation)
• These values in the Terraform resource can only be updated when the plan/apply causes the resource to be updated. The values are likely long out of date anyway, and should not be read. Using a data source instead guarantees up-to-date usage information.

Also:

The tests have been completely rewritten to use the current "self-writing" test style, and extended to test the data source (the only place where most attributes live) at the same time.

[chrismarget-j]

Closes #737

[rajagopalans]

why don't we just dump these values from the resource altogether, rather than keep them on as null resources?

[chrismarget-j]

why don't we just dump these values from the resource altogether, rather than keep them on as null resources?

They might be useful in the data source and our "shared model struct" pattern requires that the resource and data source have the same dimensions.

We could break that pattern (use different model structs for resource vs. data source), but that decision has implications for the structure of the whole project, which is something I'm not eager to tackle.

[rajagopalans]

Sounds good. I think I have asked a similar question before :-)