Summary
-------

Permanently disable remote code downloading in JNDI

Problem
-------

Remote code downloading in JNDI has been disabled by default since 8u121.
Two system properties were introduced at that time to allow selectively reenable remote code downloading in JNDI/LDAP and JNDI/RMI.
These two properties where never documented in the JDK itself, the only available documentation is in the release notes.

With the SecurityManager removed (see [JEP 486](https://openjdk.org/jeps/486)),  two system properties controlling remote code downloading in JNDI/LDAP and JNDI/RMI need to be removed: `com.sun.jndi.rmi.object.trustURLCodebase` and `com.sun.jndi.ldap.object.trustURLCodebase`. 


Solution
--------
Remove the `com.sun.jndi.rmi.object.trustURLCodebase` and the `com.sun.jndi.ldap.object.trustURLCodebase` system properties.

With both properties removed the remote code downloading is permanently disabled, unless a custom [javax.naming.spi.ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is installed to implement a custom policy for loading object factories from the `javax.naming.Reference` or the `javax.naming.Referenceable` reference objects.  For such scenarios a remote code downloading of an `ObjectFactory` class specified in a reference object fully depends on the policy determined by the installed `ObjectFactoryBuilder`.

The `javax.naming.spi.NamingManager::getObjectInstance` API documentation is updated to remove references to the SecurityManager and clarify that remote code downloading is not supported out of the box. A release note is planned to clarify that setting any of the two system properties `com.sun.jndi.rmi.object.trustURLCodebase` or `com.sun.jndi.ldap.object.trustURLCodebase` will have no effect.

Specification
-------------

src/java.naming/share/classes/javax/naming/spi/NamingManager.java:

```
@@ -123,9 +123,12 @@
      *    or {@code Referenceable} containing a factory class name,
      *    use the named factory to create the object.
      *    Return {@code refInfo} if the factory cannot be created.
-     *    Under JDK 1.1, if the factory class must be loaded from a location
-     *    specified in the reference, a {@code SecurityManager} must have
-     *    been installed or the factory creation will fail.
+     *    Downloading a factory class from a location specified in the reference
+     *    is not supported out of the box.
+     *    The {@linkplain Reference#getFactoryClassLocation() factory class
+     *    location}, if present, is ignored. A custom {@link ObjectFactoryBuilder}
+     *    {@linkplain #setObjectFactoryBuilder(ObjectFactoryBuilder) may be used}
+     *    if a different policy is desired.
      *    If an exception is encountered while creating the factory,
      *    it is passed up to the caller.
      * <li>If {@code refInfo} is a {@code Reference} or
      [....]
      */
      public static Object
          getObjectInstance(Object refInfo, Name name, Context nameCtx,
                            Hashtable<?,?> environment)
          throws Exception {

```

src/jdk.naming.rmi/share/classes/module-info.java:

An additional paragraph is added to the `@implNote`, to clarify the specific behaviour of our RegistryContext implementation:

```
+ * <p> Factory class names associated with a {@linkplain javax.naming.Reference#getFactoryClassLocation() factory
+ * class location} are not supported out of the box. Unless an {@link javax.naming.spi.ObjectFactoryBuilder
+ * ObjectFactoryBuilder} is installed a {@link javax.naming.ConfigurationException} is thrown.
  * @provides javax.naming.spi.InitialContextFactory
  * @moduleGraph
  * @since 9

```