Report warning when @SuiteDisplayName is blank

[raccoonback]

Purpose

This PR adds a discovery-time validation for @SuiteDisplayName in the Suite Engine.
If the annotation value is blank or whitespace-only, the engine now reports a DiscoveryIssue with WARNING severity.

Related issue

• Reject blank value for @SuiteDisplayName #4810

Key Changes

• SuiteTestDescriptor: invoke inspectSuiteDisplayName(...) during construction and report a warning when needed.
  (referred to DisplayNameUtils.validateAnnotation().)
• I initially considered using Preconditions.notBlank() to throw a PreconditionViolationException when the value contains only whitespace.
  However, to maintain backward compatibility, I decided that reporting a warning would be more appropriate than throwing an exception.

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[sbrannen]

I initially considered using Preconditions.notBlank() to throw a PreconditionViolationException when the value contains only whitespace.
However, to maintain backward compatibility, I decided that reporting a warning would be more appropriate than throwing an exception.

Indeed, we do not want to use Preconditions for this use case.

Even though I did not explicitly state it in #4810, the intention was to make use of the discovery issue mechanism to report a warning like with @DisplayName.

Though, for 6.0 I personally think it should be an error instead of a warning.

@marcphilipp, thoughts?

[sbrannen]

I took a quick glance and think this PR looks pretty good; however, I will probably let @marcphilipp review it as well.

In addition, I requested two very minor changes to Javadoc.

[raccoonback]

@sbrannen
Thank you for reviewing!
I’ve applied the changes based on your feedback.

[raccoonback]

@marcphilipp
I have applied the changes based on your review.
There is one point I would like to confirm with you.
Assuming that an implementation of the DiscoveryIssueReporter interface may be added in the future,
do you think we should also guard against cases where the createReportingCondition(Predicate<T> predicate, Function<T, DiscoveryIssue> issueCreator) default method is overridden to return null?
(If I’m overthinking this, please let me know...)

class SomethingDiscoveryIssueReporter implements DiscoveryIssueReporter {

 // ...

 @Override
 public <T> Condition<T> createReportingCondition(Predicate<T> predicate, Function<T, DiscoveryIssue> issueCreator) {
	return null;
 }

 // ....

}

[marcphilipp]

Assuming that an implementation of the DiscoveryIssueReporter interface may be added in the future,
do you think we should also guard against cases where the createReportingCondition(Predicate<T> predicate, Function<T, DiscoveryIssue> issueCreator) default method is overridden to return null?

No, since that method is documented to never return null, we don't have to guard against such cases. But thanks for being diligent!

[marcphilipp]

Thank you for your contribution, @raccoonback! 👍

[injae-kim]

Nice work @raccoonback 🎉🎉🎉