NIFI-15941: Allow verification to be re-attempted even if there are A…

[mcgilman]

…PI errors present.

Summary

NIFI-15941

Allow users to re-submit a Verify request in the Connector wizard after a prior backend (API) verification failure without first having to modify form values.

Problem

The SharedConnectorConfigurationStep "Verify" button is gated by stepForm.valid. When a previous Verify call returned per-field errors, the wizard store projected those errors onto the corresponding form controls under a verificationError key via verificationErrorValidator. That made stepForm.valid === false, which permanently blocked the Verify button — even though the failures are typically caused by external conditions (network, permissions, mis-provisioned external resource, etc.) that the user cannot resolve by editing the form. The only workaround was to mutate an unrelated value to trigger an error clear, which is a poor user experience.

Change

• Introduce a module-level constant VERIFICATION_ERROR_KEY = 'verificationError' and route verificationErrorValidator's error key through it, so the contract between this validator and the verify gate is named in one place. The matching template literal in connector-property-input.component.html is documented next to the constant.
• Add a private isClientValid() predicate that walks the form controls and treats a control as "valid for verify" if it is disabled (mirrors FormGroup.valid behavior for dependency-hidden properties), valid, or carries only the verificationError key. canVerify and onVerify() now consult isClientValid() instead of stepForm.valid, so prior API verification errors no longer block Verify while genuine client-side errors (required, pattern, etc.) still do.
• Rewrite updateFormValidityForVerificationErrors() to iterate every form control rather than only the keys in the current error signal. Previously, when the signal cleared (successful verify, verify start), controls still carrying a stale verificationError from a prior subscription emission were never re-validated, so the error key lingered visually. The new version handles both directions: new errors and stale errors.

Tests

Added a verify gate describe block to connector-configuration-step.component.spec.ts with 10 cases covering:

• Clean form: canVerify === true.
• API-only errors: canVerify === true, stepForm.valid === false, control reports verificationError.
• Required client error: canVerify === false.
• Hidden-dependent property that would otherwise be required: canVerify === true (disabled control bypassed, mirroring FormGroup.valid).
• Mixed client + API errors: canVerify === false (client error wins).
• In-flight verify: canVerify === false.
• onVerify() dispatches verifyStep when only API errors remain.
• onVerify() does not dispatch when a client error exists.
• Stale verificationError is cleared when the store signal empties (successful verify path).
• Per-control reconciliation when the signal transitions from {host: ...} to {port: ...}.

[rfellows]

Thanks @mcgilman 👍