Add contains methods to ByteMatcher

[fbruton]

No description provided.

[drivenflywheel]

The functionality is good, and well implemented, but the code finish in ByteMatcher.java is a bit poor:

• There are 6 new methods that are well-suited for use by downstream codebases, but none of the methods have a Javadoc comment. Especially for the methods that take parameters in the form (beginIndex, endIndex, array) or (array, beginIndex, endIndex), that's not being very kind, and likely to lead to future incorrect usage. Are the indexes in reference to the arrays that were also passed in? (no, they're not) Is the beginIndex inclusive or exclusive? Is the same true for the endIndex?
• overloads of the new methods aren't near each other. They're interleaved in no discernable pattern, which makes this file harder to read and maintain.

[drivenflywheel]

Sorry, I should have been more clear about the organizing the overloads. From the Google Java Style Guide,
Ordering of class contents:

3.4.2.1 Overloads: never split

Methods of a class that share the same name appear in a single contiguous group with no other members in between. The same applies to multiple constructors (which always have the same name). This rule applies even when modifiers such as static or private differ between the methods.

[drivenflywheel]

i.e.,

    public boolean contains(String pattern) {
        return contains(pattern.getBytes());
    }

    public boolean contains(byte[] pattern) {
        return indexOf(pattern) >= 0;
    }

    public boolean contains(String pattern, int beginIndex, int endIndex) {
        return contains(pattern.getBytes(), beginIndex, endIndex);
    }

    public boolean contains(byte[] pattern, int beginIndex, int endIndex) {
        return indexOf(pattern, beginIndex, endIndex) >= 0;
    }

    public boolean containsAll(int beginIndex, int endIndex, String... patterns) {
        return Arrays.stream(patterns).allMatch(pattern -> contains(pattern, beginIndex, endIndex));
    }

    public boolean containsAll(int beginIndex, int endIndex, String... patterns) {
        return Arrays.stream(patterns).allMatch(pattern -> contains(pattern, beginIndex, endIndex));
    }

    public boolean containsAny(String... patterns) {
        return Arrays.stream(patterns).anyMatch(this::contains);
    }

    public boolean containsAny(int beginIndex, int endIndex, String... patterns) {
        return Arrays.stream(patterns).anyMatch(pattern -> contains(pattern, beginIndex, endIndex));
    }

  ...

[drivenflywheel]

Other references, such as Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (an oldie but goodie, available in Safari Books Online), also suggest organizing overloads from simplest to the most complex, and I tend to agree with that guideline.

[fbruton]

I'll add the Javadocs once we're good with the ordering.

[drivenflywheel]

Overload ordering looks good now

[jdcove2]

The methods that have String as an argument use String.getBytes(), which uses the default Charset when converting to bytes. If these methods are to stay, then it would probably be useful to have some way of specifying the Charset to be used when converting to bytes.

[fbruton]

This is no longer a priority.