#51430: BUG in Net::LDAP::FilterMatch affecting substrings matches.

I don't know if this needs submitted here, but I figured it wouldn't hurt.

https://rt.cpan.org/Ticket/Display.html?id=51430

This is a one line fix for Net::LDAP::FilterMatch.

Using the SYNOPSIS code from Net::LDAP::FilterMatch, the results for the
ldap entry:

    dn: cn=dummy entry
    cn: dummy entry
    street: 1 some road
    street: nowhere

Are :

    (cn=dummy*) : no match
    (ou=*) : no match
    (&(cn=dummy*)(street=*road)) : no match
    (&(cn=dummy*)(!(street=nowhere))) : no match

They should be:

    (cn=dummy*) : match
    (ou=*) : no match
    (&(cn=dummy*)(street=*road)) : match
    (&(cn=dummy*)(!(street=nowhere))) : no match


I tracked this down to Net::LDAP::FilterMatch::_cis_substrings. This line:

  return grep(/\Q$regex\E/i, @_) ? 1 : 0;

Should be:

  return grep(/$regex/i, @_) ? 1 : 0;

The reason the quoting isn't needed, is because it's already done in
_filterMatch() on the line:

      $assertion = join('.*', map { "\Q$_\E" } map { values %$_ }
@{$args->{'substrings'}});

If that is then \Q...\E again, then the ".*" will get regex escaped, and
breaks.


This change may affect the following lines:

*_caseIgnoreIA5SubstringsMatch = \&_cis_substrings;
*_caseIgnoreSubstringsMatch = \&_cis_substrings;

I'm didn't dig into those, but they may need a separate subroutine doing
what the old one did.


Thanks,
--
Josh I.