"bidirectional" relationships and memberships

This was an issue which really played havoc with our operations for many days.  We eventually tracked it down, but doing so required an awful lot of debugging.

1. We created a new relationship type, with the name (in both directions) of "Associate Of".
2. Later, we realized that we wanted the relationship to have different names depending on the direction.  So we set the label a->b as "Associate Of", and the label b->a as "Associated Organization Of".
3. Much later, we created a membership type for organizations, and instructed it to be inherited according to the relationship "Associated Organization Of".  

The intention was for the membership to be purchased by organizations and inherited by their (individual) associates.

However, the membership was inherited by the associated individuals – and any organizations that they were associated with – and any individuals that they were associated with – and so forth.  It was even echoed back up so that an organization had multiple memberships, which were the grandparents of the original membership.

The problem, eventually, proved to be caused by the code in CRM_Member_BAO_Membership which tries to determine if a relationship is bidirectional, which it does by determining if the relationship name a->b is the same as the relationship name b->a.  There are three separate problems here.

A. In a relationship, the NAME a->b is set at the moment the relationship is created and can never be changed.  The LABEL a->b can be changed, but there is no indication in the interface that there is a separate NAME which is inaccessible.

B. Determining if a membership should cascade based on whether the name of a relationship a->b and b->a is the same, is really, really, really confusing to the user.  There's no indication anywhere that this will occur, especially since the interface is doing its selection based on labels but the logic is implemented via the (non-editable) names.  At the very least it should be documented better; more probably a better interface is appropriate.

C. The logic around parent-of-parent-of-parent-of... relationships is incomplete.  If (A) and (B) have a true bidirectional relationship, and (A) buys a membership, then (A) ends up with a second, child-of-child-of membership.  This is clearly not desired behavior.

Tested on 7.22 only but I suspect the issue's still around.