Consider splitting locale-fallbacking data out of icu_properties

[hsivonen]

https://github.com/servo/rust-url/issues/939 shows the build of icu_properties blocking on icu_locid_transform getting compiled. I gather the exemplar_chars module is the culprit.

We should consider splitting the exemplar_chars module, which is locale-dependent CLDR data and not locale-independent Unicode Database data into a different crate.

[sffc]

I agree there's room for improvement here. If icu_properties is all singleton keys, we could likely drop the icu_locid_transform dependency (note: crates are being reorganized in 2.0, but we wouldn't be able to entirely avoid the LocaleFallbacker dependency so long as we have exemplar chars, I think.

[Manishearth]

• @sffc - If we didn't have exemplar_chars, this is already done, right? baked data knows when it needs fallback data.
• • Yes, and there might be ways to build custom baked data and also avoid the locale fallback parameter.
• @hsivonen Custom baked data doesn't address the idna case since that uses crates.io baked data.
• • Yeah, if crates.io is desired, that doesn't work
• @robertbastian could just put behind a feature flag
• @hsivonen - As a matter of principle, why do we have CLDR stuff in icu_properties? It seems like it's a whole different thing. By what logic does exemplar chars end up in properties?
• @Manishearth We're getting icu_locale as a high level thing yes? We should boot this into there (and maybe feature gate it there)? Never made sense to me as a part of icu_properties
• @sffc - I think they went into icu_properties for lack of a better place. But now they can go into the icu_locale data-driven crate.
• • We could be proactive and, for crates that are grab-bags like locale, we could feature-gate everything. So exemplars goes into icu_locale with an on-by-default feature. Can be kicked out into a separate crate if people need.
• @hsivonen - disagree that the use case of no-data locales is small. There's a lot you can do with locales without display names or exemplars.
• @sffc - icu_locale_core exists for people who need smaller compile times and don't need exemplars and stuff
• @manishearth - either way, icu_locale has metacrate vibes to me, being proactive about features is good and helps avoid breaking --no-default-features users
• @sffc note that we can't feature gate baked data
• @manishearth true, but we can feature gate the macro invocations and that's the bulk of compile time costs
• @hsivonen - It looks like the _data crates are completely insignificant for compile times.
• @echeran - I agree with the characterization of exemplars not having a good place to go. Does it really fit in icu_locale, though?
• • It's a question you ask a locale: "what are your exemplar chars?" It would also be valid for it to live completely separately.
• @sffc - It's similar to locale directionality.
• @hsivonen - It's like talking about, what's your first day of week, what's your temperature unit. But I think displaynames should go in a separate crate.
• • I'd rather end up with too few crates now rather than splitting without people asking.
• • Agree. The main cost of splitting in the future is breaking no-default-features users, but we can mitigate that with proactive default features. And it's okay to break no-default-features users.
• @hsivonen - I observe Chrome, Safari, and Edge all patch display name data. But there's less a need to patch exemplars.

Concrete proposal:

• exemplar_chars lives in icu_locale
• feature gated, on by default
• could be split into its own crate in the future but not now
• No decision at this time on displaynames location

LGTM: @sffc @hsivonen