fix: eliminate for ... of syntax

[himself65]

  | Type                  | Node v24.4.1      | Release Build     | Change |
  |-----------------------|-------------------|-------------------|--------|
  | Raw (5 listeners)     | 166,550,996 ops/s | 168,262,835 ops/s | +1.0%  |
  | Wrapped (5 listeners) | 83,660,424 ops/s  | 88,460,347 ops/s  | +5.7%  |
  | Raw (50 listeners)    | 45,603,881 ops/s  | 47,712,200 ops/s  | +4.6%  |

Inspired from #59278

[himself65]

not going to make this ready, looks like some parts of change is unnecessary

[aduh95]

That's almost certainly less efficient, ArrayFrom iterate over the object, so we essentially double the number of iteration

[ljharb]

the loop should be converted to a callback, the second argument of ArrayFrom

[aduh95]

I would just leave the for..of here tbh, but in any case, it should be a separate PR

[aduh95]

I would try to remove that loop entirely at this point

Suggested change

	const encodings = [[kKeyEncodingPKCS1, 'pkcs1'], [kKeyEncodingPKCS8, 'pkcs8'],
	[kKeyEncodingSPKI, 'spki'], [kKeyEncodingSEC1, 'sec1']];
	for (let i = 0; i < encodings.length; i++) {
	const m = encodings[i];
	encodingNames[m[0]] = m[1];
	}
	encodingNames[kKeyEncodingPKCS1] = 'pkcs1';
	encodingNames[kKeyEncodingPKCS8] = 'pkcs8';
	encodingNames[kKeyEncodingSPKI] = 'spki';
	encodingNames[kKeyEncodingSEC1] = 'sec1';

[himself65]

yeah, make sense. we could move to a separate PR

[aduh95]

This would need to be evaluated separately

[aduh95]

If you make this PR focused on array iteration (i.e. if you remove all the ArrayFrom calls and leave other non-array iteration for a separate PR), it'd be much easier to review and approve.
I'm +1 on the idea, it also aligns with our recommendation in

node/doc/contributing/primordials.md

Lines 152 to 215 in 9239373

	<summary>Avoid for-of loops on arrays</summary>
	```js
	for (const item of array) {
	console.log(item);
	}
	```
	This code is internally expanded into something that looks like:
	```js
	{
	// 1. Lookup %Symbol.iterator% property on `array` (user-mutable if
	// user-provided).
	// 2. Lookup %Symbol.iterator% property on %Array.prototype% (user-mutable).
	// 3. Call that function.
	const iterator = array[Symbol.iterator]();
	// 1. Lookup `next` property on `iterator` (doesn't exist).
	// 2. Lookup `next` property on %ArrayIteratorPrototype% (user-mutable).
	// 3. Call that function.
	let { done, value: item } = iterator.next();
	while (!done) {
	console.log(item);
	// Repeat.
	({ done, value: item } = iterator.next());
	}
	}
	```
	Instead of utilizing iterators, you can use the more traditional but still very
	performant `for` loop:
	```js
	for (let i = 0; i < array.length; i++) {
	console.log(array[i]);
	}
	```
	The following code snippet illustrates how user-land code could impact the
	behavior of internal modules:
	```js
	// User-land
	Array.prototype[Symbol.iterator] = () => ({
	next: () => ({ done: true }),
	});
	// Core
	let forOfLoopBlockExecuted = false;
	let forLoopBlockExecuted = false;
	const array = [1, 2, 3];
	for (const item of array) {
	forOfLoopBlockExecuted = true;
	}
	for (let i = 0; i < array.length; i++) {
	forLoopBlockExecuted = true;
	}
	console.log(forOfLoopBlockExecuted); // false
	console.log(forLoopBlockExecuted); // true
	```
	This only applies if you are working with a genuine array (or array-like
	object). If you are instead expecting an iterator, a for-of loop may be a better
	choice.