feat: allow to manage display_order value for building block definiti…

[j0g3sc]

…on I/O without affecting the calculated hash for change detection

CU-86cabn76y

---

Summary

Added a manageable display_order field to building block definition version inputs and outputs.

Implementation:

Client
DisplayOrder int64 with json:"displayOrder,omitempty" on both MeshBuildingBlockDefinitionInput and MeshBuildingBlockDefinitionOutput.

Schema
display_order Int64Attribute on inputs and outputs, Optional + Computed + Default(0) — the Default is what keeps re-plans clean given the backend returns 0 when unset.

Content hash
stripped to 0 before hashing, so reordering never changes content_hash or forces a new version

Released immutability
displayOrdersDiffer guard in Update — needed because display_order is outside the hash, so this restores the "released versions are immutable" behavior with a clear error.

Mock
mirrors input→output display_order for manual BBDs.

---

⚠️ depends on meshfed-api released with https://github.com/meshcloud/meshfed-release/pull/10263

[github-actions]

📊 Test Coverage

Scope	Coverage
Unit tests (mock client)	74.9%
Combined (unit + acceptance)	80.0% — ❌ acceptance failed

❌ Acceptance tests failed (advisory — the job runs against the last merged meshfed-release backend, so a change needing a companion backend PR fails here until that backend merges; the real gate is meshfed-release's terraform-provider-acceptance job).

Uncovered functions (combined run)

github.com/meshcloud/terraform-provider-meshstack/client/api_key_permissions.go:225:							AllApiKeyPermissions					0.0%
github.com/meshcloud/terraform-provider-meshstack/client/buildingblock.go:89:								Read							0.0%
github.com/meshcloud/terraform-provider-meshstack/client/buildingblock.go:93:								Create							0.0%
github.com/meshcloud/terraform-provider-meshstack/client/buildingblock.go:97:								Delete							0.0%
github.com/meshcloud/terraform-provider-meshstack/client/client.go:48:									NewApiTokenAuthorization				0.0%
github.com/meshcloud/terraform-provider-meshstack/client/internal/logging.go:27:							Debug							0.0%
github.com/meshcloud/terraform-provider-meshstack/client/internal/logging.go:31:							Info							0.0%
github.com/meshcloud/terraform-provider-meshstack/client/internal/logging.go:35:							Warn							0.0%
github.com/meshcloud/terraform-provider-meshstack/client/internal/retry.go:228:								Close							0.0%
github.com/meshcloud/terraform-provider-meshstack/client/internal/retry.go:249:								Write							0.0%

Combined with go tool covdata merge over the unit and acceptance coverage data. The acceptance suite runs ./internal/provider against the live backend; coverage is attributed across all packages (-coverpkg=./...).

[github-actions]

⚠️ Acceptance tests failed on the latest run. This is advisory and does not block merge — the job runs against the last merged meshfed-release backend images. If this change needs a companion backend change, validate the pair via meshfed-release's terraform-provider-acceptance job; otherwise this is a regression to fix.

🔗 View the failing acceptance job

[grubmeshi]

Have a look at my proposal of implementing it differently. I think only addressing this inside the resource is not enough and it must be handled inside versionContentHash itself.

[grubmeshi]

Please address my review comments, in general, the approach is sound I think.