The solution of adding a new synchronization option seems fair to me but I don't like the approach as it does not address the alarm events for auto-resetting all..

Until now, the `datausage.js` view was observing `lastDataReset` because the chart region could vary upon this parameter, now we have another event that could raise a data request, this event is the fact we are resetting Wi-Fi **or** mobile usage. So now we have two events:
  1. Resetting some data - which is the **new one** and it's triggered always we perform any kind of reset
  2. Resetting all the data - before this patch, it was triggered by the modification of `lastDataReset`; it is fired only when we perform a complete reset or when the alarm for autoreset expires.

The second one should be renamed to `lastCompleteDataReset` as youo suggest but then, ensures it is replaced in all places where it is used now.

Once the rename takes place, we can add the event 1 which can be named `lastDataReset` (I know, this is overlapping the former name for event 2, but it does not matter now the rename has been done). Then modify `datausage.js` view and simply add another observer to react upon `lastDataReset` by requiring a new usage update.

This way, the only true variation is to react upon the new event and the renaming is only a matter of polish to provide more semantic identifiers. WTYT?