Add regexp support to service name include/exclude filters

[tigrannajaryan]

• Added regexp support to service name field in include/exclude
  filters of attributes processor. This makes it consistent with
  span name fields which already use regexp patterns.

• Added match_type to make service name and span name matching explicit.

Testing: added unit and E2E tests.
Documentation: README modified as appropriate.

[codecov-io]

Codecov Report

Merging #522 into master will increase coverage by 0.17%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #522      +/-   ##
==========================================
+ Coverage   76.06%   76.24%   +0.17%     
==========================================
  Files         126      126              
  Lines        7860     7917      +57     
==========================================
+ Hits         5979     6036      +57     
  Misses       1584     1584              
  Partials      297      297

Impacted Files	Coverage Δ
processor/attributesprocessor/attributes.go	95.31% <100%> (+1.31%)	⬆️
processor/attributesprocessor/factory.go	95.52% <100%> (+1.23%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 47ccdff...19efa6d. Read the comment docs.

[owais]

Probably a bit late but we could support regex and exact both with same fields while still making it very explicit and obvious.

config:
    match: <string_to_match>

config:
   match: /<regexp>/

Enclosing the value in / would force a regex match otherwise an exact string match.

Don't know if it's worth doing now but in future if we need to support both regex and exact matches for the feature, we could follow this pattern. I think it'll be intuitive if all components follow the pattern.

[tigrannajaryan]

Probably a bit late but we could support regex and exact both with same fields while still making it very explicit and obvious.

config:
    match: <string_to_match>

config:
   match: /<regexp>/

Enclosing the value in / would force a regex match otherwise an exact string match.

Don't know if it's worth doing now but in future if we need to support both regex and exact matches for the feature, we could follow this pattern. I think it'll be intuitive if all components follow the pattern.

Not too late. Let me explore this.

A couple things that are not immediately clear. What happens if I want to strict match a strict that start with a forward slash? Am I forced to use a regexp in that case? Given that forward slash is a URL path component starting character it may be a non-rare case.

It may be confusing that adding a forward slash at the beginning of a rule changes the matching rule. Can be unexpected if the user doesn't read the docs.

[pjanotti]

LGTM

[tigrannajaryan]

Probably a bit late but we could support regex and exact both with same fields while still making it very explicit and obvious.

config:
    match: <string_to_match>

config:
   match: /<regexp>/

Enclosing the value in / would force a regex match otherwise an exact string match.
Don't know if it's worth doing now but in future if we need to support both regex and exact matches for the feature, we could follow this pattern. I think it'll be intuitive if all components follow the pattern.

Not too late. Let me explore this.

A couple things that are not immediately clear. What happens if I want to strict match a strict that start with a forward slash? Am I forced to use a regexp in that case? Given that forward slash is a URL path component starting character it may be a non-rare case.

It may be confusing that adding a forward slash at the beginning of a rule changes the matching rule. Can be unexpected if the user doesn't read the docs.

@ccaraman any thoughts on this? ^^^^

[pjanotti]

@tigrannajaryan @ccaraman @owais I like the idea ˆ
I think it could become a standard for how we do matching stuff, for consistency we should use all around: even if a component just supports regex it should still use the / ... /syntax so it can report errors like: "exact match is not supported by xyz processor" (although it seems hard to have a component that supports only regex).

[ccaraman]

one tiny nit