NIFI-15779 Allow error message to appear on controller service ui when service is enabling but not valid

[NissimShiman]

Summary

NIFI-15779
Besides the specific case in the jira, this is useful for cases where a controller service is ghosted or is using an invalid property value (as a result of a migration) and the service is trying to enable but is invalid.

There is now an error icon next to the controller service.

Logic was added to keep the logging manageable, as the framework retries to enable the service.

Tracking

Please complete the following tracking steps prior to pull request creation.

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

Licensing

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

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for proposing this change @NissimShiman. This introduces some arbitrary delay numbers, and although the comments are helpful, this appears to revert back to some previous behavior. In addition, the change to declare the message before completeExceptionally() does not appear to be needed.

Rather than introducing this approach, it seems like some other strategy could provide a better way of surfacing enabling failures.

[NissimShiman]

Thank you @exceptionfactory for looking at this.

Could converting LOG.warn() to componentLog.warn() be a better approach?