On the test, we're adding 2 RSPs:
RSP1: SF1, SF2, SFF1, SFF2. Using NSH (VXLAN encapsulation)
RSP2: SF3, SFF3. NSH-VXLAN also

The sequence of actions leading to this bug being reproduced:

1: Create RSP1
After that, the internal table "rspNameToFlowsMap" (which contains information used for deleting flows when RSPs are deleted) in SfcL2FlowWriter contains two entries:
a) "SFC" RSP, with initialization flows for SFFs 1 & 2 -> 12 flows
b) RSP1 (5 flows / SFF) -> 10 flows on this case

2: Create RSP2.
Initialization flows for SFF3 are added to "SFC" entry in rspNameToFlowWriter table, , and also a new table entry for the flow itself. So the table content at this point is the following:
a) "SFC" RSP key, with initialization flows for SFFs 1 & 2 & 3 -> 18 flows
b) RSP1 -> 10 flows
c) RSP2 -> 5 flows

3: Delete RSP2.
Here is where the bug is triggered. After deleting the RSP, the table state:
a) "SFC" RSP -> Still contains 18 flows (i.e. initialization flows for SFF3 are not removed): this is the leak
Also, it can be observed that initialization (matchAny) flows are not deleted from SFF3 (those are the flows left behind at deletion)

The problem is in the "clearSffIfNoRspExists" method in SfcL2FlowWriterImpl class. It only deletes initialization flows when ALL RSPs are deleted; but this is too coarse: initialization flows for each SFF should be accounted separately, so when no RSPs for the SFF remain, initialization flows for the SFF are removed.

Just for your info, I plan to submit a renderer patch in the following days (it introduces transactional flow write/deletion for all flows when the RSP is created/deleted, which can be seen also as a fix for https://bugs.opendaylight.org/show_bug.cgi?id=4806), which includes two new unit tests currently nonpassing because of this bug. The tests check flow creation + internal state for the Create:RSP1->Create:RSP2->Delete:RSP2->Delete:RSP1 and Create:RSP1->Create:RSP2->Delete:RSP1->Delete:RSP2 sequences