With [[ https://github.com/wikimedia/wikipedia-ios/pull/3648 | initial ("v1") release of EPC-iOS ]] getting finalized, there are some changes/improvements and features we're noticing that should be included in a revision ("v2").
 Restoring event persistence so we accumulate events in offline mode (this is an alternate, and probably more reliable way to accomplish offline event logging than waitsForConnectivity). We will need to persist both input and output buffers so we don't lose them between app termination and launching, before they are able to POST. For future reference, the version of the library [[ https://github.com/wikimedia/wikipedia-ios/pull/3648/commits/0699c3ed063cf7fe9d0f8c9a974ab775af9ebfc0 | at this commit ]] has the StorageManager functionality in place.
 Posting scheduled events in the background (https://github.com/wikimedia/wikipedia-ios/pull/3648#discussion_r483223851) //(possibly moot if persistence is solved)//
 Batch send multiple events with one call (https://github.com/wikimedia/wikipedia-ios/pull/3648#discussion_r483096817, related: T239996)
 `Session` with `waitForConnectivity` (https://github.com/wikimedia/wikipedia-ios/pull/3648#issuecomment-686566272) //(possibly moot if persistence is solved)//
 General thread-safe arrays (https://github.com/wikimedia/wikipedia-ios/pull/3648#discussion_r482126861)
 Stream config fetching should be re-tried several times throughout session, including getting triggered by network connectivity
 Possible consistency issues with the legacy system:
 The legacy system EventLoggingService.swift has Wifi-only logic for a day that then switches to LTE. That could be the cause of some discrepancies between the systems, so should we duplicate this logic into the EPC library?
 We should dig into which error types are considered network failures that merit retries between both systems and understand if they need to match.
 We should dig into which HTTP status codes are considered successful posts between both systems and understand if they need to match.