Bug 2402

It seems a potentially infinite number of forwarded (M)profiles can end up being
held in TAO_Stub in a chain from the most recently received back to the first
forward received in the life of the object. As best as I can tell these have a
close to zero chance of being ever used again except under this unusual
circumstance:

Assume the stub holds a chain of n forwarded MProfiles (1 the oldest, n newest),
and it is communicating (successfully) with the object represented by n. n
issues a location forward to object n+1 *but* n+1 is unreachable at the point of
connection establishment. The connection attempt will get retried but *only*
with the *previously untried profiles* from n (then ditto on n-1; n-2; etc.. if
there are any). In the usual case world of single profile IORs (or for most
multiprofile IORs that are not IOGRs) this means that the stub has been holding
a string of profiles just to be able to delete them all at this point before
throwing an exception.

If I read it right, in all other scenarios and at all other times any problem in
communication will result in an immediate fallback to the base profile
discarding the whole forward chain. This is horribly inconsistent from a users'
perspective and it's very wasteful potentially hanging onto great chunks of
useless memory.

Proposal 1: Change TAO_Stub::add_forward_profiles to delete everything before
the last good (i.e. current connectable) forwarded profile when a new profile is
added. If the new forwarded profile cannot be connected to, go back and try
*all* the profiles on this last forwarded one then fall back to the original
base profiles if that fails. This will should give the best chance of avoiding
an exception to the client and is more consistent but may lead the unwary into
location forwarding loops.

Proposal 2: Keep one forwarded profile only in addition to the original base. If
you get a forward in: Try all it's profiles and then if you couldn't connect
just propogate the exception to the client and reset back to base profiles.

Proposal 3: If it is still felt that we really have to keep the current
behaviour then we should:
1/ Check for ::is_equivalent with the new head of the queue against all previous
entries (removing the one that is equivalent if it exists). This will at least
prevent us from holding multiple copies of the same data in the event where you
have been forwarded from A -> B -> ... -> A.
2/ At the same point remove any previous MProfiles from the chain that had all
their profile(s) tried in the original connection attempt. It is pointless to
store them - this will include all single profile IORs.

Probably won't get to this until after 1.5. Comments and opinions welcome in the
meantime.