Work around problem w/ large CalendarProvider2 transactions

* We're seeing binder transaction failures when we try to send more than around
  1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
  usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
  create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
  much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
  exceptions once we reach half of the maximum number of CPO's.  This has been
  determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
  to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
  of a "fix", rather than a workaround, can be implemented

Bug: 2760514
Change-Id: I06ca1a1ae88c772342a9e46b5997c41678e95144
2 files changed