Add subset of dates data to DataProvider

[zbraniecki]

This PR introduces a subset of ca-gregorian from cldr-dates that will be needed for initial DateTimeFormat.

See: https://github.com/unicode-cldr/cldr-dates-modern/blob/master/main/en/ca-gregorian.json

The PR operates on Cow everywhere, but once we land DateTime we may want to switch some of them to Pattern structs if we measure performance wins with no significant payload growth.

[coveralls]

Pull Request Test Coverage Report for Build d5278718a395b54b2e37b937155eae457a452eb4-PR-256

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+4.005%) to 82.941%

---

Files with Coverage Reduction	New Missed Lines	%
components/data-provider/src/data_key.rs	2	25.0%

Totals
Change from base Build 1f08acccfec3fd1800c8fad8fbe43fabb3ffb652:	4.005%
Covered Lines:	1867
Relevant Lines:	2251

---

💛 - Coveralls

[sffc]

Thanks! This is definitely on the right track. Left some comments.

[zbraniecki]

Thanks for the review! I filed #257 to discuss how should request/response look like for Dates.

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• components/data-provider/src/structs/dates.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• components/data-provider/src/structs/dates.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• components/data-provider/src/structs/dates.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[zbraniecki]

I updated the PR to reflect Shane's initial comments.

I have two follow up PRs that I'd like to start getting ready to land, but cycling 4 PRs in git is a mess (Mercurial solved it years ago so well!).

Shane, how far do you think this is from being landable?
I understand that we'll continue iterating over it as I pull DateTimeFormat and this together, and I'm comfortable removing DateTimeFormat from 0.1 release if we feel like it's not in shape by the time 0.1 is ready, but I'm concerned about the mental overhead of juggling those PRs.

[sffc]

You are using Options in order to make data requests smaller. But, at the same time, you are putting everything in one big struct. I think that's a conflicted design that we need to solve.

It makes no sense to me to have Options for symbols and date patterns. What are you supposed to do if the data provider gives you one but not the other? Option should be used only if you can fall back within the data key, such as between plural forms, where Option is warranted. Fallback between locales should be handled on the data provider level. ICU4X should never need to request the same key multiple times from the data provider!

I would like to either:

1. Remove the Options, or
2. Split the data into the three keys I suggested (datesym, timesym, and dtpatterns).

[zbraniecki]

@sffc I removed the options, and we can revisit the splits later.

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• components/data-provider/src/structs/dates.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[sffc]

Thanks! I'm approving but I still have questions/comments/suggestions.

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• components/data-provider/src/structs/dates.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• components/data-provider/src/structs/dates.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[sffc]

LGTM. We should have a real Default implementation for the date symbols, but we can do that later:

#260