Get test data rework

[dsweber2]

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

make get_test_data retrieve a year by default, and make predict narrow down to the forecast_date

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

• Resolves #{issue number}

[dajmcdon]

@dsweber2 How important do you think this methodology is? Just a thought, but what if we

1. deprecate this function completely;
2. only call forecast() in examples (rather than predict());
3. Inside of forecast(), just predict the entire training data, then filter to the reference date.

[dsweber2]

if the fitting is expensive, it's probably best to predict as few days as possible (I've run into this with grf). Having something that handles that filtering is probably worthwhile.

That said, the most important part of this PR is definitely the filtering the output in the way predict runs so that it's only outputting forecasts for the right days. In practice that was the part that tripped me up more when avoiding get_test_data in exploration-tooling

[dajmcdon]

Just to be clear, get_test_data() has nothing to do with model fitting, only the amount of preprocessing necessary. Computation could hit in two ways:

1. Long running steps (step_growth_rate() would be such) that bog down on excess data; although the growth rate calculation is an example of a case where the current implementation becomes very fragile, and this fix would help;
2. Actually predicting on the inputs; this is unlikely to cost very much in most cases. Tree predictions are very fast, as are linear models.

Where are you imagining the hit is occurring? I agree that point 1 is a reason to avoid predicting on excess data (and one reason for implementing this function in the first place), but my current thinking, after much use, is that the fragility is a larger issue than the computation. Do you have examples where the cost to 1 is burdensome?