Bug 1091

In a client, if the server's IOR is provided with two almost identical
profiles that differ only in the host form, for example one containing the
host in the form of an IP address and the other containing the host's
machine name, JacORB will resolve the machine name into its IP address and
then the two profiles become identical.

In this situation, if the server is offline and a call to it is made, the
following occurs (when using DefaultProfileSelector):

   1. The call is attempted using the first profile's address and a
   TRANSIENT is thrown.
   2. Before returning the call to the client application JacORB sees that
   there are more profiles so proceeds to select the next one.
   3. Since both are equal, DefaultProfileSelector returns null, which
   nullifies the effectiveProfile in the ParsedIOR object.
   4. This leads to a COMM_FAILURE in the next call using the same proxy
   object, when I believe it should still be a TRANSIENT. The proxy does not
   recover from this and will forever throw COMM_FAILURE.

The logic to return null if two profiles are equal in
DefaultProfileSelector seems to be there to prevent a loop in the iterator,
I guess. Besides not accounting for the presented problem, I'm not sure it
should return null in any case where there are profiles to try since
ParsedIOR puts any return it gets into effectiveProfile.

Just removing lines 95-100 from DefaultProfileSelector.java fixes the
COMM_FAILURE and passes the entire JacORB test suite (except for JacoTest
which was already failing before), but I'm not sure this is correct or the
right fix. I did this trying to mimic DefaultProfileSelector's behaviour
before the bug was introduced on commit
c6570906b3fa05a4afa420033188b428ccce612c.

(reference on list = http://lists.spline.inf.fu-berlin.de/pipermail/jacorb-developer/2016-October/000833.html)