Add an IntlMemoizer as an argument that can be shared between MessageContexts

[zbraniecki]

This will allow us to implement https://bugzilla.mozilla.org/show_bug.cgi?id=1475356 and utilize a shared intl memoizer between contexts.

[stasm]

Let's remove this method completely and use ctx._intlMemoizer directly in the resolver (in types.js).

[stasm]

We can remove some boilerplate by subclassing WeakMap here.

[stasm]

Also, should we export IntlMemoizer in index.js?

[stasm]

This looks rather Pythonic to me :) Sadly, it won't work in JS. id is a new object literal every time this code runs. cache.has(id) will always be false.

[Demivan]

@eemeli This, probably, can be closed now. #504 implements this functionality.
Edit: And #218

[eemeli]

@Demivan Good point, this does look obsolete. @zbraniecki, would you agree?

[zbraniecki]

umm, this is actually concerning. With #504 we just made it mandatory for bundles to share memoizer. My mental model is that we should be careful about it as there may be side effect of crating opportunity for one bundle to affect another by tainting the shared memoizer and its cache.

In my vision we would by default isolate memoizers per bundle or registry, and allow users to volunteerily provide a shared memoizer to be used.

This way the API is explicit about "this bundle shares memoizer with other bundles" and noticeable to the consumer in any security review.

This would also make it easy to align with multithreaded implementations of Fluent (like fluent-rs) where the option to pass a memoizer wouldn't be available so the default behavior would be the same (isolated memoizers), while the optional "pass a shared memoizer" wouldn't which is reasonable.

[eemeli]

@zbraniecki While I get your point about there being a possible security concern in the now-merged shared memoizer allowing for an Intl object to be a communication pathway between bundles, I have two follow-on questions:

• As we currently consider the memoiser as an internal implementation detail, are you ok with Add per locale Intl memoizer #504 having been merged, or should it be rolled back?
• For runtimes that need to take this into account as a security concern or otherwise, should the memoiser sharing be controllable per-bundle or per-runtime? As in, if we want to prevent some sharing should we then prevent all sharing?