Experience has taught us that the client needs the session
data (current user, list of groups) and set of enabled feature
flags at the same time, and also needs to invalidate them
in the same scenarios (eg. account switching).

Fetching this data via two separate requests made it more complicated
to ensure the client had a consistent view of session and feature-flag
data. To simplify things and also same a network request:

 * On the server, put the feature flag data into the session data payload.

 * On the client, use the existing central storage and cache management
   for the session data payload to manage feature flags as well.

   The features service now becomes a thin wrapper around part of
   the session state.