Fix another rate limiting corner case with custom rate limit settings #202
Description
There was another rate limiting edge case bug similar to the issue we identified yesterday in #201. This one came thanks to an open source user of API Umbrella in NREL/api-umbrella#127
Basically, the bug only occurred when the following steps were taken:
- An admin edits a user and assigns a custom rate limit to the user. The admin saves the user.
- The admin then edits the user and removes each custom rate limit explicitly, but keeps the rate limit mode still as "custom" (if the admin just flips the rate limit back to "default", then this problem doesn't occur). The admin then hits save.
In this case, that specific api key essentially has it's rate limits removed, which obviously isn't good. Also un-intuitively, even if the admin then flips this user back to have "default" rate limits, the problem still persists once the user is saved in this state.
Luckily, I don't think this sequence of steps in the admin has been very common. There was only one api key in our database with this setup, but that user hasn't actually been active.