feat(rum): apply a rate that leaves zero to the running session

[Fiona2016]

A session sample rate published above 0 now ends the session of a visitor whose
session was drawn at 0, so collection starts at their next interaction rather
than waiting for that session to rotate — up to four hours. It joins the two
changes that already did not wait: a stricter default privacy level, and a rate
of 0.

This is the case where waiting shows an operator who has just switched collection
on nothing at all, and nothing at all is indistinguishable from a broken
integration.

Why only a session drawn at 0

The rule is written against the rate the session was drawn at, not against
whether it is currently being collected. Re-drawing every session that is not
collected would spare the winners and re-roll the losers, so a fleet drawn at 20
and moved to 50 would come out at 60. A rate of 0 is the one value with no
winners to spare — nothing was collected and no coin was flipped — so re-drawing
everyone lands exactly on the new rate.

A rate rising from one real value to another still waits for the next session, as
before: only a second draw could say whether a session drawn at 30 should have
been kept at 80, and drawing twice turns a rate p into p².

Recording the draw of a sampled-out session

Answering that question needed a record such a session never had. A session that
loses its draw is given no id, so its draw was not recorded at all and the rate it
was drawn at fell back to the init value — which reads a session that lost a draw
at 30 as one drawn at 0, the bias above. Its draw now goes into the same single
localStorage entry a collected session's goes to, under an id no session can
hold, so neither can read the other's. No new storage entry and no extra request.

That sentinel shares one id across every sampled-out session, so the id check that
makes a stale record inert for a collected session does nothing there. What
replaces it: the page that draws owns the slot. reportDraw now hands over every
draw rather than only the ones worth keeping, so a draw landing on the init values
clears the record instead of leaving the previous session's behind to answer for
it.

Also

Resolving a rate runs the site's beforeSampling callback, so it is now asked
only where the answer settles whether the session ends, rather than once per
delivered configuration for every visitor.

Tests

yarn test:unit — 2998 passing. Nine tests added, two that asserted the previous
behaviour removed. Each new rule was checked by reverting the implementation and
confirming the intended tests fail:

• a rate leaving zero ends the session; a partial rate does too
• an init rate of zero with the first delivered settings
• the session that follows is collected
• a session that lost a draw at a real rate is left alone (the bias regression)
• the drawn rate read back through storage across a page load
• a replaced session is not answered for by the previous session's record
• no repeated re-draw once the replacement has lost a draw at the new rate
• beforeSampling not consulted when no rate could decide anything