Enable batching multiple events into a single POST request over buffer size if maxPostBytes setting is followed

[matus-tomlein]

This PR enables POST requests to contain more events than configured through bufferSize as long as they don't surpass the maxPostBytes.

The reason for this is to send events queued up in the event store in a single POST request rather than individually. This may happen for instance if some events didn't manage to be saved on the previous page visit (or the collector was not reachable). With this feature, they should be sent in one batch request on the next visit.

It may also happen in events are tracked right after each other – if they manage to be saved to the event store before the flush function is called, they will be batched together.

The change might be useful also with issue #1355 where part of the problem could be too many requests done shortly after each other.

[bundlemon]

BundleMon

Files added (6)

Status	Path	Size	Limits
✅	trackers/javascript-tracker/dist/sp.js	+24.35KB	30KB / +10%
✅	libraries/browser-tracker-core/dist/index.mod ule.js	+23.45KB	25KB / +10%
✅	libraries/tracker-core/dist/index.module.js	+19.18KB	20KB / +10%
✅	trackers/browser-tracker/dist/index.umd.min.j s	+17.26KB	20KB / +10%
✅	trackers/javascript-tracker/dist/sp.lite.js	+17.22KB	20KB / +10%
✅	trackers/browser-tracker/dist/index.module.js	+3.49KB	5KB / +10%

Total files change +104.95KB 0%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history

[jethron]

Nice fix! Batching works as expected again with this change, I can trigger 100 events in quick succession and it's split into 3 batches, rather than 100 requests without this change.

The Content-Length is slightly larger than maxPostBytes though, should we take this opportunity to account for payload_data overhead or something? Even just a static >= (maxPostBytes - 200) or something would probably be adequate. (We've suggested this setting to some people who have a WAF in front of the collector that blocks requests over a certain size; ideally we'd treat it a bit more strictly, but doesn't have to be perfect; we can always just advice under-specifying it.)

My comment above should help address #1355, let me know if you want me to do a dedicated PR or you can just include it here.