[#709] Enable disabled and invisible tests across the sibling modules

[vharseko]

Context

Follow-up to the slow group audit (#684-#706): an inventory of tests that never run in the sibling modules — both enabled = false methods and test classes whose file names do not match the surefire include patterns.

Commit 1: four tests disabled without any stated reason

• LDIFEntryWriterTestCase.testSetAddUserFriendlyComments, LDIFChangeRecordWriterTestCase.testSetAddUserFriendlyComments (opendj-core) — pass as-is (both classes 84/84 green).
• GrizzlyLDAPListenerTestCase.testLDAPListenerLoadBalanceDuringHandleAccept — passes as-is.
• GrizzlyLDAPListenerTestCase.testLDAPListenerProxyDuringHandleAccept — contained a copy-paste error: the client connected to the online server directly instead of to the proxy listener, so the proxy handleAccept was never invoked and the test timed out. It now connects to the proxy listener.

Commit 2: rotted disable reasons and a product NPE

• TemplateTagTestcase → TemplateTagTestCase: the lowercase "c" never matched the *TestCase include pattern, so its 21 tests have never run (all pass).
• Product fix: PropertyDefinitionUsageBuilder.visitString() threw a NullPointerException for string properties which define a pattern but no pattern synopsis, breaking error message generation for pattern validation failures — the "I18N problem" that kept two StringPropertyDefinitionTest methods disabled since forever. The synopsis is now appended only when present; both tests enabled.
• Stale disable reasons — all pass now, twice in a row, together with their neighbouring classes:
  • ValidateConfigDefinitionsTest.validateConfigObjectDefinitions ("TODO: can't retrieve object class objects") — 37/37;
  • DefaultTCPNIOTransportTestCase.testGetInstance (unclean-environment FIXME) and ConnectionFactoryTestCase.testSchemaUsage (OPENDJ-159) — grizzly module 2×88/88.

Still disabled, with valid reasons

• EntryGeneratorTestCase.printEntriesToStdOut — debug printer, not a test;
• GSSAPISASLBindRequestTestCase.testBindClient — requires a Kerberos KDC;
• BasicRequestsTest.testReadSelectPartialInsensitive — CREST-86, confirmed still failing (case-insensitive JSON field selection returns null);
• the Windows-only FileManagerTest case.

Verification

opendj-core 84/84 + TemplateTagTestCase 21/21; opendj-config 2×42/42; opendj-grizzly 2×88/88 (plus two earlier 10/10 listener runs).

[maximthomas]

Should this TODO be removed?

[vharseko]

Good catch — thanks. Removed, but the TODO turned out to point at a real problem, so I did more than delete it (e1c6fe8):

• The test only stayed green because its assertion was inverted (errors.length() != 0), i.e. it passed precisely when a definition had problems. With the correct == 0 it fails for all 37 definitions.
• The cause is exactly what the TODO said: the ds-cfg-* LDAP schema is not on the opendj-config test class path, so object classes / attribute types resolve only as placeholders (verified: getObjectClass("ds-cfg-backend") → 0 required / 0 optional attrs; getAttributeType("ds-cfg-java-class").isPlaceHolder() == true). That schema is generated in opendj-server-legacy.

So I reworked it into a naming-convention validator: fixed the assertion to == 0, dropped the schema-dependent checks (attribute-exists / single-vs-multi-valued / mandatory / allowed-attribute), and kept the checks verifiable from the definitions and their LDAP profiles alone. Fixing the assertion surfaced three real issues, now fixed:

• CLASS_OBJECT_CLASS_EXCEPTIONS referenced the obsolete org.forgerock.opendj.config.std.meta package, so root/global were no longer excluded → updated to org.forgerock.opendj.server.config.meta.
• http-endpoint's authorization-mechanism intentionally maps to ds-cfg-http-authorization-mechanism → added an LDAP_ATTRIBUTE_NAME_EXCEPTIONS list for such deliberate deviations.

37/37 green now, and a negative-control run (removing the http exception) confirms the check still fails on a real deviation.