Add support for recording state in localStorage rather than cookies

This is to help minimize overall HTTP header size.

Most servers only allow up to 4kb (Akamai default); some will bump this to say 16kb but this can still not be enough for some user’s accumulated cookies on one request. Having such big HTTP headers increase the total size of all upstream requests and binds a lot of memory on server requests and therefore reduces the number of possible concurrent connections.

We have future proofed our client_session schema to record where the session is stored: https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.snowplow/client_session/jsonschema/1-0-1#L33

So hopefully it is not a huge change to support this? The only note is that we should add a new Tracker Protocol parameter (maybe we won’t flow it through Snowplow right now) to track what storage we are using for this session, so that:

1. we can fully back-populate client_sessions contexts from TP parameters when we finally switch to using client_session for web
2. if a user switches the storage, we have a theoretical way of untangling changing session identifiers (because they won’t survive the switch) (theoretical because if we don’t represent the new param in atomic.events, it will be very hard to review)

[falschparker82]

This affects us as well, as we’re using the Javascript SDK inside Ionic / Cordova. We have a heavy problem with duplicated first sessions across users on mobile, as cookies apparently don’t stick:

Affected users:
90% of all ios users
0,3% of all web users
43,7% of all android users

[alexanderdean]

Changed the title to prevent confusion between recording state and tracking events