Instantiation of feature group connections can create unnecessary connection instances

[AaronGreenhouse]

Consider the example below:

• There is a feature group with both a port feature and a data access feature
• The feature groups is used as a on a thread
• The thread has a data subcomponent that is connected to the data access feature of the feature group

The instance model will have

• A connection instance (through the feature group connection) that goes directly to the data subcomponent (as fixed in issue #2032)
• Two connection instances consisting of just the feature group connections: one between the data sub features and one between the subprogram access features of the feature groups. These exist because the port connection and the fact that we stop at edge of thread for port connections we will create a connection instance between the thread and the other thread. This is good. But because we unwrap the contents of the feature group, we also end up with a connection instance between the two data access features of the threads.

package ExtraConnection
public
    feature group FG1
    	features
    		output: out data port;
    		shared_sub: provides subprogram access;
    end FG1;
    
    feature group FG2
    	features
    		input: in data port;
    		provided_sub: requires subprogram access;
    	inverse of FG1
    end FG2;
    
    thread T1
    	features
    		fg1: feature group fg1;
    		output: out data port;
    		shared_sub: provides subprogram access;
    end T1;
    
    thread implementation T1.i
    	subcomponents
    		s: subprogram;
  	 	connections
    		xxx: subprogram access s <-> fg1.shared_sub;
    		yyy: subprogram access s <-> shared_sub;
    end T1.i;
    
    thread T2
        features
            fg2: feature group fg2;
            input: in data port;
            provided_sub: requires subprogram access;
    end T2;
    
    thread implementation T2.i
    end T2.i;
    
    process p
    end p;
    
    process implementation p.i
        subcomponents
            t1: thread t1.i;
            t2: thread t2.i;
        connections
            cc: feature group t1.fg1 <-> t2.fg2;
            dd1: subprogram access t1.shared_sub <-> t2.provided_sub;
            dd2: port t1.output -> t2.input;
    end p.i;
    
    system Root
    end Root;
    
    system implementation Root.impl
        subcomponents
            p: process p.i;
    end Root.impl;
end ExtraConnection;

Thus we have an extra data access connection that we shouldn't have and isn't present if you do the same with with just features and not feature groups. The above example has the following connections currently:

The unwanted extra connection instance is t1.fg1.shared_sub -> t2.fg2.provided_sub.

Lutz suggests the following to deal with this problem:

Is the longer correct connection always inserted before the shorter incorrect one? The we could brute force it by comparing the shorter connection to all existing connections and not inserting it if it's contained in an existing one. IIRC we have similar code to detect duplicates, already.

[lwrage]

Fixed in 16b4255 (and 1b43a6a)