feat: sync push

[tm-ruxandra]

Description

Integrate change-tracking, local soil data logic, and soil data push endpoint into full push system. This is comprised of the following notable pieces:

• The PushDispatcher component listens for unsynced soil data and, when the app is online, dispatches a push to the server. It will also initialize a retry cycle on failure, which will end the next time the soil sync state changes (i.e., if a push succeed, the user makes new changes, or offline status changes.)
• soilIdSlice has been updated to ingest push results using the applySyncActionResults method, which handles updating internal recordkeeping based on push operation results. In particular, it only ingests results that are "up-to-date" (the result is for the same revision ID as the record's current revision ID).
• The sync model has been updated to include support for sync errors. Records which had an error on the last sync are still considered 'synced' until their next change and retain the last-known 'successful' data.
• remoteSoilDataActions contains logic for turning the ChangeRecords representing a user's un-synced changes into input for the Push mutation.
• soilDataDiff contains the bare-minimum logic needed to compare soil data versions, so that we can indicate to the server when a depth interval has been removed. (To be expanded upon in [Offline] Field-level change tracking for mobile client push #2283)
• The sync file has been split into revisions, records, and results for better separation of concerns and readability.

Checklist

• Corresponding issue has been opened
• New tests added

Related Issues

#2279

Verification steps

1. Open the app in offline mode, make changes, then go online; observe that changes made are synced when app goes online.
2. Open the app in online mode, make changes; observe that changes are periodically synced to the server.
3. Simulate server errors on the push endpoint (e.g., randomly fail). Observe that changes are still synced to server eventually once operation succeeds.
4. Verify that making additional changes while a retry is active aborts that retry and pushes the new changes.
5. Verify that toggling online status while a retry is active aborts that retry, and pushes the new changes when online.

[shrouxm]

ok, did a first pass. i would say the only comment that feels kinda blocking-ish is the ask for tests on the PushDispatcher

separately, i feel like it would be really nice to have some good documentation of how the sync system works, i spent a while staring blankly at sync.ts which i think is partly because i just have a hard time keeping the high-level view of the system straight in my head while going through the weeds of the code, which would be alleviated by a proper write-up