Add 5 min lookback for immutable streams to prevent missing records

[dmosorast]

Description of change

We've observed a situation where events and balance_transactions can skip data when the record gets created exactly on (or very near) a date_window break. There appears to be some amount of time between when a record is stamped as created and when it's made available by the API. Likely only on the order of seconds.

For example

1. Balance Transaction BT1 gets created at 1574260351.
2. Tap, due to configuration and happenstance of timing, issues a request with parameters created[gte]=1574258564&created[lt]=1574260351&limit=100
3. BT1 does not get returned with this result set, but the tap bookmarks the second after its created time, so it never gets re-requested

The Fix
This PR is to add a 5 min lookback window to the start_date of all requests for balance_transactions and events. 5 minutes was chosen to account for potential scenarios when Stripe is under load and this lag time becomes on the order of minutes.

• The assumption is that 5 minutes shouldn't increase duplicates too much

Outstanding
This is likely also an issue for the "creation" of other streams' records, but since they are mutable, the record gets captured due to the events_updates pattern and causes them to be caught if missed.

Keeping this scoped to only the immutable streams to keep the surface of the change low.

Manual QA steps

• Ran this for balance_transactions and events, and it was able to advance the bookmarks.

Risks

• Row volume and time-to-sync could increase in situations where transaction and event volume is extremely high. I don't suspect this is cause for concern.

Rollback steps

• revert this branch or adjust the lookback