I am fine with this PR, though I generally disagree with the underlying approach of this PR, because I feel it removes clarity and mangles previously useful definitions.

Previously, there was a clear definition:

• we partition the consensus committee into "internal nodes" and "partner nodes"
• "partner nodes" are the nodes whose private key we don't have access to
• for "internal nodes", we have the private keys

The problem was that we didn't comply to this definition and had nodes appear in both sets. But instead of fixing this problem, I think this PR just adds a work-around that makes this one particular instance of the code tolerate this technically incorrect configuration.
How do we know that there aren't other places, where we rely on the convention that internal nodes and partner nodes don't have any overlap? If that was the case, we are just removing some check that would us prevent from proceeding with such a conceptually inconsistent configuration (overlap between partner and internal nodes). Now the changes are higher that we'll just generate incorrect results (overlap between partner and internal nodes) instead of failing.

Significantly weakening a clear definition introduces ambiguity and thereby additional error surface to the code. Lets at least add some minimal documentation about what is going on and what we mean with the terms "internal node" and "partner node", how we are deviating from dis convention in the code. Otherwise, we just layer on technical debt.