Configurable notification limits

[dgw]

The code is very naïve right now, and just spits out a list of commits pushed. Even if there are dozens of them. That's not very friendly unless the module is enabled in a dedicated "dev" channel (and even then, it runs into flood protection pretty quickly). We should have a way to set limits on events like pushes, which can possibly contain many sub-items.

I would have just knocked this out real quick, but there's no way to access bot.config from the code that generates the messages. So it's a bigger project, suitable for the next version bump instead of the next patch release, and some thought will have to go into how passing the options around should work (so other hooks' behaviors can also be made configurable using the same tools).

The best way might be storing an options object (JSON or whatever, the format isn't important) in the database alongside the repo:channel pairs, since the plugin has to go fetch things from there anyway (like the colors to use).

[HumorBaby]

I would love to help with this.

Just so I can try cobbling some stuff together to get the ideas flowing, would you mind sharing some of the payloads (assuming you accept my help 😁) for some problematic pushes (e.g., line notes, multiple commits, ...) so I can use them for testing?

[dgw]

Would be happy to provide what I can, but ignoring for now based on @HumorBaby's IRC follow-up.

[dgw]

Part of the original comment here (spam from multiple pushed commits) is also covered by the separate issue #53. They're technically different problems, but still related.

I've amended the OP to clarify, as this issue is different from #54 (filtering webhook events on the bot side instead of manually toggling payload types on GitHub's end).

[dgw]

Bumped along with #53, as the same webhook rewrite will help both.