fix(core) promise_id should be 32bit instead of 64bit

[inteon]

Extracted this inconsistency fix from #9457.

[bartlomieju]

@inteon I'm not sure this change is preferable; running out of 32bit promise ids could be possible after few hours of server running. What's the reasoning behind this change?

[inteon]

In MinimalOp, i32 is used for promise_id and in json_ops u64 is used.
In javascript the promise_id is only converted to a big int BigInt(promiseId) before it is passed to rust.
I'm trying to make all these promise_ids the same length.
But, like you said, maybe 64 bits should be used?
I would then change i32 to u64, and use BigInt in js for the counter too.

[bnoordhuis]

Conversion to BigInt isn't necessary and introduces a small performance penalty.

2^32 is too small but JS numbers are exact up to 2^53 and that's still unfathomably large (good for the next 285 years at a rate of 1 million promises/sec.)

[inteon]

Ok, I get it now; in javascript a Number is used, which is more performant than an BigInt and can represent integer values up to ±2^53 − 1 exactly (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Numbers_and_dates).

In order to send these 53 useful bits, setUint32 cannot be used.
Instead the Number is converted to a BigInt so it can be used in setBigUint64.

To summarize:

• in rust a promise_id is an u64
• in javascript a promise_id is a Number
  Because of js, the usable promise_id range is [0, 2^53 - 1], so 11 js <-> rs transferred bits will be left unused.

I will change the MinimalOps behavior to match this, and this PR is no longer relevant.