NIFI-16183 Add active-polling stopConnector(Duration) to connector mock framework

[wkochman]

Summary

Tracked by NIFI-16183.

The connector mock server previously stopped a Connector with a single fixed 10-second blocking wait (connectorNode.stop(flowEngine).get(10, TimeUnit.SECONDS)). On slower shutdown paths (for example, a failed table still draining) that wait can expire even though the Connector node retries its stop internally and eventually reaches STOPPED, so an otherwise-passing test fails during teardown with a TimeoutException.

This change adds a timeout-aware, active-polling stop to the connector mock framework:

• ConnectorTestRunner: adds a default void stopConnector(Duration timeout) overload that delegates to the no-arg method, keeping it backward compatible for existing implementors.
• StandardConnectorMockServer: initiates the asynchronous stop and then polls the Connector state until it reports STOPPED within the supplied timeout, instead of a single fixed blocking wait. The node flips its state to STOPPED at the same point it completes the stop future and retries a failed component stop internally, so polling rides through those retries up to the timeout. Defaults: 60-second budget, 250 ms poll interval; a healthy stop still returns immediately.
• StandardConnectorTestRunner: passes the timeout through to the mock server.
• CreateConnectorIT: adds an integration test that exercises the new overload end-to-end against the real GenerateAndLog connector.

Tracking

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Note: contrib-check was run on JDK 21 (Temurin 21.0.5), scoped to the affected connector-mock bundle reactor (./mvnw -f nifi-connector-mock-bundle/pom.xml clean install -P contrib-check, all 9 modules). Checkstyle (0 violations), apache-rat, PMD, and the enforcer rules all pass; external dependencies were resolved from the local repository. The new integration test was run separately via the integration-tests profile: Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 for CreateConnectorIT#testStopConnectorWithTimeoutStopsRunningConnector. A full-repo contrib-check and a JDK 25 build have not been run.

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy (no new dependencies are introduced)
• New dependencies are documented in applicable LICENSE and NOTICE files (no new dependencies are introduced)

Documentation

• Documentation formatting appears as expected in rendered files (no documentation changes)

[markap14]

An explicit timeout should probably result in a {{java.util.concurrent.TimeoutException}}, rather than a RuntimeException, no?

[wkochman]

make sense, I have changed it on the new method

[wkochman]

The Ubuntu Java 21 integration-tests leg failed on an unrelated flaky test, not on anything in this PR (which only touches nifi-connector-mock-bundle).

The failure is in nifi-couchbase-processors:

[ERROR] PutCouchbaseIT.testPutDocument:61 Expected all Transferred FlowFiles to go to success but 1 were routed to failure

The backing Couchbase Testcontainer never came up:

com.couchbase.client.core.error.ConfigException: Could not locate a single global configuration
java.util.concurrent.TimeoutException: Did not observe any item or terminal signal within 10000ms in 'source(MonoDefer)'
NativeIoException: recvAddress(..) failed with error(-104): Connection reset by peer

So PutCouchbase routed a FlowFile to failure because the container was unreachable. All JDK 21/25 unit-test legs and the validation checks passed. A re-run of the failed job should clear it.