Disallow configuring filters with both manual and generated topic lists

[dylanjw]

What was wrong?

Related to Issue #975

How was it fixed?

Only allow configuring log topic filters via the topics or argument_filters parameter and not both.

Cute Animal Picture

[dylanjw]

@pipermerriam This could use another review. I added another bugfix to the topic list construction by removing the permutation of the full topic list by the topic options. Options are passed as lists in place of the bare topic string when multiple topics are to match on one argument. ie:

[ event_sig_topic, [option1_for_arg1, option2_for_arg1], arg2_topic ]

[carver]

This API change doesn't have any downstream effects in the public API?

[dylanjw]

There shouldn't be a bad effect. Because the topic list permutations were removed, construct_event_topics only needs to return a nested list when there are multiple options for a single argument filter.

There was a bug in how the topic list was being generated. This is an example of a correctly formated topic list to match logs with either of two values for the first indexed event arg:

[ event_sig_topic, [option1_for_arg1, option2_for_arg1], arg2_topic ]

whereas this is what we were generating to be equivalent to the above; we would pass full topic list permutation against each option:

[
    [ event_sig_topic, option1_for_arg1, arg2_topic ],
    [ event_sig_topic, option1_for_arg1, arg2_topic ]
]

This topic topic list actual means: any of [event_sig_topic, option1_for_arg1, arg2_topic ] in the first position and any of [event_sig_topic, option1_for_arg1, arg2_topic] in the second position. Node filters don't understand nested lists as full topic lists. The spec defines a single topic list that can have nested lists of options for each positional element.

[dylanjw]

I can break this part out into another PR, and add a failing test.

This issue has been fixed in the new api: #953. Im fixing this function to make it easier to integrate the new filter builder api.