fix: update for compatibility with epiprocess==0.9.0

[dshemetov]

Checklist

Please:

• Make sure this PR is against "dev", not "main".
• Request a review from one of the current epipredict main reviewers:
  dajmcdon.
• Make sure to bump the version number in DESCRIPTION and NEWS.md.
  Always increment the patch version number (the third number), unless you are
  making a release PR from dev to main, in which case increment the minor
  version number (the second number).
• Describe changes made in NEWS.md, making sure breaking changes
  (backwards-incompatible changes to the documented interface) are noted.
  Collect the changes under the next release number (e.g. if you are on
  0.7.2, then write your changes under the 0.8 heading).
• Consider pinning the epiprocess version in the DESCRIPTION file if
  • You anticipate breaking changes in epiprocess soon
  • You want to co-develop features in epipredict and epiprocess

Change explanations for reviewer

Updating for epiprocess changes here cmu-delphi/epiprocess#477.

The main changes are:

• epi_df metadata reconstruction needed to change somewhat - we no longer allow duplicate time_values per epi_key group and we make this check in the constructor, so it no longer works to just do as_epi_df(result) and append the metadata. But the fix is simple as_epi_df(result, as_of = old_meta$as_of, other_keys = old_meta$other_keys).
  • removed some remaining bits of additional_metadata = list(other_keys = ...) in epi_df constructors
  • other_keys can no longer be NULL in epi_df constructors, so a few %||% character() addins
• we changed key_colnames in epiprocess to return geo_value, other_keys, time_value (since that makes the most sense when grouping and ordering epi_dfs), so I propagated the change to the key_colnames here as much as I could.
• epi_slide argument renames (dot prefixes) and converting from before/after to window_size/align
• reran the canada grad student dataset because its other_keys was still stored in the additional_metadata list

Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch

• Resolves #{issue number}

[dajmcdon]

The main things are the change in the ordering of the keys. Is there a reason for this? Preference? Were they changed on the relevant epiprocess branch?

[dajmcdon]

Trying to keep these in the same order as https://github.com/cmu-delphi/epiprocess/blob/16f38b2b386522f7f8f4880157432a3fa4a8d6ae/R/epi_df.R#L168.

Does this break something?

[dshemetov]

This is updated in our upcoming epiprocess PR. If this line isn't changed then the wrong columns are associated with the wrong roles.

[dajmcdon]

I see. Is there a reason for that choice? I think the previous ordering was based on a Slack vote that @brookslogan took a while back? I can't seem to find it.

[dshemetov]

I think the Slack vote asked for people's preference for the order to add arguments to a function, not how they want to order their epi_df.

[brookslogan]

(Right, and this was about API data-fetching functions, rather than epiprocess ones. In arrange_canonical I think we just borrowed this vote without doing another one... and I do wonder about my polling methodology anyway.)

[dajmcdon]

I'm approving, subject to resolving the remaining bits.

[dshemetov]

Did a hotfix to the date validation code in layer_forecast_date and layer_target_date for now, but I can handle this better in another PR #390.