Tracing: make filtering logic more intuitive for multiple categories

Tracing: make filtering logic more intuitive for multiple categories

This changes the way category filter processes multi-categories groups.
Previously, adding a disabled-by-default- category to a regular category
would prevent the event from matching filter if only regular category
is enabled. This is somewhat counter-intuitive, the expected behavior
is that each category is processed by the filter independently. The new
logic is:

1. if at least one category in event category group matches at
least one category enabled in the filter, the event passes;

2. if at least one category in event category group matches at least
one category explicitly excluded in the filter, the event is
filtered out;

3. the event is passed by default, if included categories list is empty
and event has at least one category that is not disabled-by-default-.

Note no existing tests were modified (though I'm not sure if (2) should
be the way it is).

BUG=

Committed: https://crrev.com/5262e5a158f6302eb4dac49d416b1a00f37186ba
Cr-Commit-Position: refs/heads/master@{#308136}

[caseq, 2014-12-10 16:24:10]

caseq@chromium.org changed reviewers:
+ dsinclair@chromium.org, junov@chromium.org

[caseq, 2014-12-10 16:24:11]

I was merely adding another category to an existing trace event in
https://codereview.chromium.org/785913003/, but it turned not a safe thing to
do, as it caused the event to be filtered out due to the way filter logic is
implemented. Let's change it to a more intuitive one, as specified in the
description?

[dsinclair, 2014-12-10 16:31:26]

dsinclair@chromium.org changed reviewers:
+ nduca@chromium.org

[dsinclair, 2014-12-12 15:16:09]

On 2014/12/10 16:31:27, dsinclair wrote:

Before we do this, can you do a check on the current traces and see if there are
any "foo,disabled-by-default-bar" that we'd suddenly start emitting that we
didn't before?

The disabled-by-default categories are usually pretty heavy, which makes me
nervous that we'll slow something down accidentally.

(In general, I agree that the filter is wonky and hard to use, I like the
approach here, I just want to make sure we won't have other side effects if we
go down this road.)

[caseq, 2014-12-12 17:45:16]

On 2014/12/12 15:16:09, dsinclair wrote:
> On 2014/12/10 16:31:27, dsinclair wrote:
> 
> Before we do this, can you do a check on the current traces and see if there
are
> any "foo,disabled-by-default-bar" that we'd suddenly start emitting that we
> didn't before?

I went through the list of categories I got at runtime and then for a code
search to see if there are any that were not hit at run-time, and I can't see
any cases where we presently mix regular and disabled-by-default categories
(except for the one I was trying to land in the CL referred above).

[dsinclair, 2014-12-12 17:51:38]

The CQ bit was checked by dsinclair@chromium.org

[dsinclair, 2014-12-12 17:51:39]

lgtm

[commit-bot: I haz the power, 2014-12-12 17:53:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/788243003/1

[commit-bot: I haz the power, 2014-12-12 19:00:47]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-12-12 19:01:33]

Patchset 1 (id:??) landed as
https://crrev.com/5262e5a158f6302eb4dac49d416b1a00f37186ba
Cr-Commit-Position: refs/heads/master@{#308136}