Fix for cycle detection issue

[lhstrh]

Fixes #2033.

[lhstrh]

Looks like the code I touched is also used for federation to figure out the topology. For cycle detection, a physical connection should break the cycle, which it does now, but it makes federated tests fail. Not sure how to address this. @edwardalee, could you take a look?

[edwardalee]

It is not surprising that this change would cause failures. It changes the semantics of the eventualDestinations method. I'm surprised there aren't unfederated failures. I also think that excluding connections with delays is suds. Maybe this is related to federated failures with multiport's and delays?

[lhstrh]

To me, it is surprising. This code is used for causality analysis in the validator. Maybe it should not be, but for that use, connections that are physical or have delay should not imply dependencies.

[edwardalee]

The eventualDestinations method comment says this:

   * Return a list of ranges of this port, where each range sends to a list of destination ports
   * that receive data from the range of this port. Each destination port is annotated with the
   * channel range on which it receives data. The ports listed are only ports that are sources for
   * reactions, not relay ports that the data may go through on the way. Also, if there is an
   * "after" delay anywhere along the path, then the destination is not in the resulting list.

I think your reasoning is that a physical connection is much like an after connection with an unspecified amount of delay. This is reasonable, so changing this method (and its description) is defensible, but it still means making sure that all uses still work. If I had to guess, there is a place where this method is used to set num_destinations, and maybe this is being used in federated execution.

[byeonggiljun]

@lhstrh I fixed the compile error by not assigning the TPO level to physical connections and added a test for this PR's change. Could you review them?

[petervdonovan]

I'm not aware of any way that these changes could cause problems. I think it's true that physical connections do not need to be addressed in TPO.

[lhstrh]

This looks like the right solution to me!