Reduce confusion for comments that use common emojis

[asvoboda]

Occasionally we have internal discussions about the use of :+1: or 👍 as approval mechanisms. Usually this is because it can feel a bit magic if policy-bot accepts this in the context of a comment with other text where someone might not intend to approve a PR.

We should consider if there are ways to reduce this confusion:

• Should we modify the approval comment matching to not look for substrings, but instead match on exact text (probably without whitespace?) This would be a breaking change.
• Should there be a server option to "restrict" comments to exact matches? Similar to above but as an option rather than always modifying the behaviour in code?
• Remove +1s in our internal policies and don't change anything in policy-bot?
• Something else?

[bluekeyes]

I agree the existing default behavior of substring matching was probably a mistake, but I'm not sure we want to change the behavior of the app at this point given existing usage. Either way, I don't think we need to change how the comments method works, given you can use comment_patterns to achieve the "full match" behavior.

My proposal for this is that we:

1. Implement Support rule defaults for common options #41 to allow default approval methods for all rules in a policy
2. Add support for a server-level default configuration that applies when policies don't specify their own
3. For our internal usage, change the default approval methods at the server level to allow only GitHub reviews and comment patterns that match the full comment

We could then discuss switching the hardcoded defaults from using comments to using comment_patterns. This would be a behavior change, but people could restore the old behavior if they wanted using the server-level default mechanism above.

[bluekeyes]

As of 1.40.0, it's now possible to override the default approval methods in the server. Internally, we're using the following defaults:

  approval_defaults:
    options:
      methods:
        comments: []
        comment_patterns:
          - "^\\s*:\\+1:\\s*$"
          - "^\\s*👍[\\x{1F3FB}-\\x{1F3FF}]?\\s*$"

To maintain compatibility, I don't think we'll change the hardcoded defaults, but it's something to consider if we ever release a 2.0.0 version with other breaking changes.