Calendar usage limits

[benjcunningham]

This hasn't hit a Travis build yet, but as of this evening, local tests on functions that POST are getting this error in their JSON responses:

"error": {
  "errors": [
   {
    "domain": "usageLimits",
    "reason": "quotaExceeded",
    "message": "Calendar usage limits exceeded."
   }
  ],
  "code": 403

From this administrator help page:

Calendar usage limits exceeded. This is the result of an API call. (Don't mix this up with the message "Daily quota exceeded," which points to insufficient API quota.)

...

Why is this happening? Google Calendar puts certain limits in place to protect our users and infrastructure from abusive behavior. When these limits are reached by a user, Google Calendar will go into read-only mode for that user, and all edit actions will fail for a certain period of time. Most users will never hit these limits, as they are well above the activity level of a typical Calendar user.

And then there's this:

Resolution If users hit the Google Calendar limits, they should be able to edit their calendars normally again within several hours. Users will still be able to view events in Calendar during that period.

And finally this:

If a user sees one of these messages it’s probably due to one of the following reasons:

Creating too many events If a user has created more than 10,000 events in his or her calendar within a short period of time, that user might lose calendar edit access.

Creating too many calendars If a user creates more than 25 new calendars within a short period of time, that user's calendar might go into read-only mode.

There are a couple more possible reasons for the error listed, but I imagine the problem is creating 25+ calendars within a short (how long?) period. This is kind of annoying, since it's no doubt triggered by the tests.

Probably not the biggest issue, since there's rarely even 25 builds in a day (assuming we can limit each run to creating only one calendar), but this might be a sign that we need to handle these kinds of errors better (the httr:stop_for_status most of the HTTP VERBs use only prints a 403 error).