Make attribute localization "pull" rather than "push"

[stasm]

When localizing DOM elements, we currently try to set all attributes we find defined in the localization. There's a sanitization step which filters attributes missing from the default allowed list or attributes which haven't been explicitly allowed with data-l10n-args.

I think we should double down on this sanitization design and make attribute localization pull rather than push. For any given DOM element, the bindings would only format the known allowed attributes.

This would allow the low-level code in Localization to never have to inspect the inner representation of a message, as it does right now:

fluent.js/fluent-dom/src/localization.js

Lines 213 to 221 in 5786bf9

	if (msg.attrs) {
	formatted.attributes = [];
	for (const [name, attr] of Object.entries(msg.attrs)) {
	const value = ctx.format(attr, args, errors);
	if (value !== null) {
	formatted.attributes.push({name, value});
	}
	}
	}

[stasm]

The same applies to fluent-react:

fluent.js/fluent-react/src/localization.js

Lines 55 to 60 in 5786bf9

	if (msg.attrs) {
	var attrs = {};
	for (const name of Object.keys(msg.attrs)) {
	attrs[name] = mcx.format(msg.attrs[name], args);
	}
	}

[zbraniecki]

For any given DOM element, the bindings would only format the known allowed attributes.

Would that mean that, at runtime, every Node would have to loop through two whitelists (general and per-element) scanning for attributes?
In my experience, most elements have one or two attributes, so the current code has O(2), while the new loop would be O(x) where x= ALLOWED_ATTRIBUTES['global'].length + ALLOWED_ATTRIBUTES[elemName].length.
That would potentially bring up performance implications at scale of 500 elements on a hotpath.

[stasm]

For n elements to localize, we're talking O(2n) vs. O(xn) for x < 10. I don't think this is where we should look for performance improvements. (I think it's IO, parsing and touching DOM, but I'll be happy to be proved wrong).

I know you care about perf and memory, so perhaps I can sweeten this idea by saying that doing this would allow us to skip the creation of intermediate objects in

fluent.js/fluent-dom/src/localization.js

Line 214 in 75f57aa

formatted.attributes = [];

and

fluent.js/fluent-dom/src/localization.js

Line 218 in 75f57aa

formatted.attributes.push({name, value});

? :)

It would also bring us closer to being able to remove getMessage entirely, which in turn might help with our FFI story, because we'd only have hasMessage -> bool and format -> String.