Add dateRange to core/user store

Feature Description

In preparation for refactoring date range select boxes to use the datastore, we need to first add dateRange state and functionality to the core/user datastore.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• There should be a new assets/js/googlesitekit/datastore/user/date-range.js datastore module which is combined into the core/user store in its index with the following components:
  • selectors.getDateRange - returns the current date range slug
  • actions.setDateRange( slug ) sets the current date range by its slug
• The initial dateRange should be last-28-days for now although in the future this may be persisted from a previous choice
• There should be a new assets/js/googlesitekit/datastore/user/date-range.test.js adding test coverage to the new components
• There should be a new utility function (not in datastore) getAvailableDateRanges() that returns an array of objects like:

  {
  	slug: 'last-28-days',
  	label: sprintf( __( 'Last %d days', 'google-site-kit' ), 28 ),
  }
  

Implementation Brief

• Add a getDateRange() selector that returns the currently-selected date range slug, eg: 'last-7-days'
• Add a setDateRange( slug ) action that sets the active date range using a slug like "last-28-days".
• The state’s defaults should be what would be set by setDateRange( 'last-28-days' )
• Add a utility function (getAvailableDateRanges()) that returns an object where the key is the date range slug, and the value is an object with the date range slug and its translation (I think that’s [ 'last-7-days', 'last-14-days', 'last-28-days', 'last-90-days' ], but check existing code to make sure I’m not missing anything). It would have the shape: {'last-7-days': {slug: 'last-7-days', label: _n( 'Last %s day', 'Last %s days', 28, 'google-site-kit' ) }}

QA Brief

Changelog entry

• Add getDateRange() selector and setDateRange( slug ) action to the core/user store.

[felixarntz]

Returning an object here makes sense, since it allows for quick lookup by slug. QA ✅

[felixarntz]

Mostly SGTM, but a few points of feedback:

• getActiveDateRange should be getDateRange.
• I agree with @tofumatt on not returning localized values. I also think the available date ranges should not be managed by this store at all, they can be in a utility function getAvailableDateRanges that could include localized values, potentially even functions to transform to startDate and endDate or something like that. I think we should remove getAllDateRanges as a selector and instead have a decoupled utility function.
• Changing the slug approach to something more sophisticated should either not happen at this point, or we should take the time to think it all the way through. I’m not sure a number + dateUnit approach satisfies the needs in a future-proof way. From that POV, the slug is actually better because it doesn’t restrict us to any convention (but clearly has other trade-offs). A good idea here is to look at the additional date ranges that some parts of the AdSense module support and from there determine how we can abstract it into something more structured than a slug.