This is an umbrella item for JNDI SQE test co-location

Overview
--------------
Current JNDI regression tests are few and overall code coverage is low. These are rough coverage statistics based on 9 b155:

    java.naming module is 47% method coverage, or 37% block coverage.
    jdk.naming.dns moduel is 44% method coverage, or 38% block coverage.

We have a suite of SQE tests with better coverage, but they are very old (most of tests are developed in last century 1999) and hard to be maintained. In additional, it uses the legacy test harness and the execution is only supported by Aurora, which has been removed from support since JDK 10 and beyond.

In order to streamline test maintenance and execution, we propose to migrate valuable JNDI SQE tests to jtreg regressions tests and retire the old SQE test suite.

Migration Strategy
--------------
QE will review existing SQE test suites and functional coverage to decide which tests will be converted. It is possible not to convert 100% of the SQE suite into regression, just choose the scenarios which make sense to the test coverage.

JNDI related codes were contained in 4 modules, java.naming, java.corba, jdk.naming.dns, and jdk.naming.rmi. Breaking down the existing SQE tests:

    We will focus on ldap and dns SQE test suites, which cover java.naming and jdk.naming.dns.
    Simply ignore the corba related test suites. According to JDK-8189188, the JNDI CosNaming provider (from java.corba) will no longer be available.

In SQE test suites, both LDAP and DNS tests depend on real Directory servers. This is not a good choice for new regression tests in openjdk. We propose:

    to use dummy socket server playback dump message to simulate real environment. This approach has already been used in current LDAP regression tests in openjdk (jdk/javax/naming/module).
    For dns parts, since there is no similar build-in property to trace protocol messages like ldap, we need to implement a DNS tracer which can dump DNS protocol messages. And a dummy DNS server to playback those messages.

Typical migration steps:

    Create a plain regression test from existing SQE tests.
    Run the test against real server to trace messages and save into file.
    Run test against dummy server playback to verify everything is fine.
    Put trace message file (in plain text with hexadecimal dump) aside the regression test.
    Review as usual regression tests.

There could be limitation with this practice, some cases (such as response message changed every time or complex multiple request) may not be supported in this approach. We may figure out other solution if necessary.