Smarter rate control for IOT etc.

@rxl881 was experimenting with IOT integrations earlier and rapidly hit ratelimiting problems.

The good(?) news is that we don't yet ratelimit on federation, so we're free to make the CS API smarter. Suggestions are:

• Rate limit per-user. This has the disadvantage that a server admin will have to reach down from the heavens and explicitly configure config or something for particular sets of users. This feels fragile and kludgy, and overlaps with the current AS-configuration stuff where we can configure rate limiting for particular namespaces of users (but only if they're an AS).
• Rate limit per-room(-per-user). This is nicer as we can just store it in room state, and people can set it based on power levels. It has the disadvantage though that after rate-limiting has been disabled in a huge room, someone can accidentally/deliberately still DoS the server out of existence. This could be extended to per-room-per-user rules too (i.e. let this particular user talk fast in this particular room) but that feels a bit overkill.
• Rate limit per-room(-per-user), but with units being egress-msg/s rather than ingress-msgs/s This might be quite an elegant solution to prevent server overload. By specifying the limit in egress-msg/s, you can be confident that a room won't sprout lots of users and then overload the server - and it lets server admins specify a meaningful global cap per-server too. (i.e. configure that no user is allowed to trigger more than 100 egress messages per second, or whatever).

However, implementationwise, i'm a bit worried that different APIs will have different limiting thresholds depending on the room that they interact with - and that the HS will have to query the room state every time someone says something to decide how limited they should be.

Thoughts? @erikjohnston @NegativeMjark @Kegsay and anyone else.

Review the three proposed rate-limiting models and the concerns about room state, API thresholds, and egress limits. Done requires a decided approach for smarter CS API rate control; the issue names no files, tests, or implementation entry points.