Bug 5417: An empty annotation value does not match

[rousskov]

Helpers may return annotations with empty values:

OK team_=""

A note ACL may be configured to match an annotation with an empty value:

configuration_includes_quoted_values on
acl emptyTeam note team_ ""

However, that emptyTeam ACL did not match the above helper annotation:

• AppendTokens() split an empty annotation value into an empty vector
  instead of a vector with a single empty entry. That "never match an
  empty value received from the helper" bug was probably introduced in
  2017 commit 75d4734 when it replaced an "always try to match an empty
  value, even when it was not received from the helper" bug in
  ACLNoteStrategy::matchNotes().

• ACLStringData::match(SBuf v) never matched an empty value v. That bug
  was probably introduced in 2015 commit 76ee67a that mistook a nil
  c-string pointer for an empty c-string.

[rousskov]

Thank you, @eduard-bagdasaryan. It looks like the bug reporter may use a workaround instead of testing these changes, so our own lab testing may be the best we can do for now. I am removing the draft flag from this PR and plan to clear it for merging in a few days.

[rousskov]

Computing this complement is a fairly expensive operation. Its result cannot be cached because delimiters may change from one call to another. If we want to optimize this and similar code, I see two options:

1. Add Tokenizer::prefixUntil() or similar method that takes delimiters instead of their complement.
2. Make CharacterSet::compliment() fast, either by always storing and maintaining complement (doubling memory usage requirement) or by storing a "reverse every comparison" flag (slowing down every comparison a little). In either case, we would have to make CharacterSet::Storage shareable across CharacterSets (to make CharacterSet copies cheap).

The first option looks significantly better to me because it does not slow down every CharacterSet test. In other words, the first option does not hurt any caller performance, while the second option hurts every caller performance (a little). The first option is also much easier to implement, and it does not make the rest of the affected class code more complex.

I consider this optimization, regardless of the implementation option, outside this bug-fixing PR scope.