[Exporter Refactor] Onnx sub graph matching

[corey-nm]

This adds a function (get_structural_matches) that allows us to find all sub-graphs in an onnx graph that match a specific structure. Much of the code in the existing passes exists just to match sub-graphs, and it all follows a similar pattern. This function allows us to compactly and explicitly specify what we want to match against. It also retrieves the actual nodes for us and makes using them simple.

See docstrings for more information.

Testing plan

unit tests & we converted two complex passes to use this function in this PR (#1200), which is tested by unit tests

[dbogunowicz]

Sweet

[bfineran]

Looks amazing @corey-nm most comments around structure.

Also suggest adding support for "or"s. maybe handling tuples in this case where something like ("Gemm", "MatMul") would come in handy

[bfineran]

small overall nit - logic flow might be a little cleaner splitting by type instead of going by negations. (for example here we need to check for initializer stuff when we really just care about node protos)

[bfineran]

do we want to protect more for user input error here?
might be especially tricky for ops with lots of inputs (think maybe qlinearconv). is it a requirement to have an entry for each input?

[corey-nm]

Its actually necessary to not match exactly against length. e.g. "QuantizeLinear" has 3 inputs but with our recursion we only ever match against 1 input.

So the only checks right now are just to ensure that then length is at least the length of the actual parents.

[bfineran]

ah I see, so the only issue would be if we want to skip over any of the first k inputs to match against any later ones, then they'd need to add placeholder [].

like if we want to match to a QuantizeLinear with an initializer zero point for example it would be [[], [], [INITIALIZER]]?

[corey-nm]

Yep exactly!

[bfineran]

any reason not to assert an == against the actual expected lists or even expected match objects?
that way we could pull everything into a parameterized test function

[corey-nm]

Since the elements of parents/children are nodes i wasn't sure how to match against them without transforming it in some way

[bfineran]

makes sense.

we can still combine this logic, if we want to accept a list of expected node names, parent names, and children names.

not necessary now if crunched for time, but will make refactors and adding new tests a lot easier

[corey-nm]

Yeah I like that idea, will do when more rigorous testing is added for this function

[bfineran]

LGTM pending ACK of comments

[bfineran]

makes sense.

we can still combine this logic, if we want to accept a list of expected node names, parent names, and children names.

not necessary now if crunched for time, but will make refactors and adding new tests a lot easier