Never pass a NoOp value to an op

[mattsoulanille]

The 'NoOp' op appears in the execution graph (although it shouldn't really), and its output value can sometimes be passed to downstream nodes. Temporarily fix this by filtering it out of the parameters in getParamValue.

TODO(mattSoulanille): Refactor the graph so NoOp and other control dependencies are only used for sorting and don't appear in the execution graph.

To see the logs from the Cloud Build CI, please join either our discussion or announcement mailing list.

---

This change is 

[pyu10055]

Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: complete! 1 of 1 approvals obtained

[Linchenn]

LGTM

[chunnienc]

It looks like most of the usage of getting tensor list param value treat it as unknown size list, but some of it does extract positional tensors from the list (Code Search, notice the search result only convers function calls in a single line, so the actual use cases may be more.) But I believe this PR won't affect those since param tensors shouldn't come from NoOp node.

[mattsoulanille]

It looks like most of the usage of getting tensor list param value treat it as unknown size list, but some of it does extract positional tensors from the list (Code Search, notice the search result only convers function calls in a single line, so the actual use cases may be more.) But I believe this PR won't affect those since param tensors shouldn't come from NoOp node.

Yeah, and that's why I would like to rewrite this solution later, since it doesn't guarantee the length of the returned list if there's a NoOp node as an input. This kind of error should really be caught in graph analysis instead of model execution. I agree that for correct graphs, we should never encounter this kind of parameter shortening, but I still don't really like it.