Fix hard-coded condition_template_id allow-list rejecting valid platform templates

[soumyas-dev]

Fix hard-coded condition_template_id allow-list rejecting valid platform templates

Fixes #432

Problem

resource/xray_custom_curation_condition restricted condition_template_id to a
hard-coded stringvalidator.OneOf(...) of 9 template IDs. The set of templates
Xray actually supports is dynamic — it is returned by the
GET xray/api/v1/curation/condition_templates API and varies by JFrog Platform
version and enabled features (e.g. malicious-package detection).

As a result, valid platform templates such as isMalicious, NoLicense, and
aged-package variants were rejected by the provider at terraform validate/plan
time, before the request ever reached the API:

Error: Invalid Attribute Value Match
condition_template_id value must be one of: ["OpenSSF" "BannedLabels"
"AllowedLabels" "SpecificVersions" "AllowedLicenses" "BannedLicenses"
"CVECVSSRange" "isImmature" "CVEName"], got: "isMalicious"

The schema description itself already stated the value is "One of the IDs of the
supported condition templates returned by the list condition templates API" — but
the validator contradicted that by baking in a static list.

Fix

1. Removed the hard-coded OneOf on condition_template_id (kept
   LengthAtLeast(1)). The Xray API is the source of truth and returns a clear
   Unknown ConditionTemplateId '<id>' error for genuinely invalid IDs.
2. Deferred parameter validation to the API for unrecognized templates. The
   param_values validator still fully validates templates the provider knows
   about (param names, counts, required params, value types), but for any template
   not in its internal map it now validates only JSON syntax and defers the rest to
   the API — so new/platform-specific templates aren't blocked by provider-side
   param rules.
3. Updated the schema description to explain the value is not restricted
   client-side.

Reproduction & verification

Reproduced with a locally-built provider (dev override):

Scenario	Before fix	After fix
condition_template_id = "isMalicious"	❌ Invalid Attribute Value Match at validate	✅ provider validates; deferred to API
Known template (CVEName) + valid params	✅	✅
Known template (CVEName) + invalid param_id	❌ errors (correct)	❌ still errors (correct)

On the test platform (Xray 3.143.30) the condition_templates API returns only
the original 9 templates and rejects isMalicious with
Unknown ConditionTemplateId 'isMalicious' — confirming the template set is
platform-dependent and that the API correctly gatekeeps invalid IDs once the
client-side block is removed.

Tests

Added TestAccCustomCurationCondition_PlatformSpecificTemplate_NotRejectedClientSide.
It uses a PlanOnly step with condition_template_id = "isMalicious", so it
exercises the config-level validators (where the OneOf lived) without requiring
the backend to support the template. It fails before the fix
(Invalid Attribute Value Match) and passes after. Existing acceptance tests for
the known templates continue to validate parameters exactly as before.

Changelog

Added a 3.1.12 BUG FIXES entry.

[srinivasgowda097]

LGTM