fix: use uuid package instead of crypto for remote http jupyters

[frtennis1]

Closes #244

[domoritz]

Can we use uuid only as a fallback? Or even just use a pseudo random counter? It really isn't necessary to have something complicated here as we just try to match requests.

[frtennis1]

I believe the uuid package already implements the function by falling back to the native crypto implementation if it is accessible. In particular, I looked into the generated index.js ESM -- here is the diff that is created,

<     const a = Ap(e.partition).map((c) => t.maybeParam(c));
---
>     const a = $p(e.partition).map((c) => t.maybeParam(c));
30159c30159,30188
< async function ZZ(e) {
---
> let ol;
> const UZ = new Uint8Array(16);
> function qZ() {
>   if (!ol && (ol = typeof crypto < "u" && crypto.getRandomValues && crypto.getRandomValues.bind(crypto), !ol))
>     throw new Error("crypto.getRandomValues() not supported. See https://github.com/uuidjs/uuid#getrandomvalues-not-supported");
>   return ol(UZ);
> }
> const be = [];
> for (let e = 0; e < 256; ++e)
>   be.push((e + 256).toString(16).slice(1));
> function jZ(e, t = 0) {
>   return be[e[t + 0]] + be[e[t + 1]] + be[e[t + 2]] + be[e[t + 3]] + "-" + be[e[t + 4]] + be[e[t + 5]] + "-" + be[e[t + 6]] + be[e[t + 7]] + "-" + be[e[t + 8]] + be[e[t + 9]] + "-" + be[e[t + 10]] + be[e[t + 11]] + be[e[t + 12]] + be[e[t + 13]] + be[e[t + 14]] + be[e[t + 15]];
> }
> const VZ = typeof crypto < "u" && crypto.randomUUID && crypto.randomUUID.bind(crypto), _2 = {
>   randomUUID: VZ
> };
> function YZ(e, t, n) {
>   if (_2.randomUUID && !t && !e)
>     return _2.randomUUID();
>   e = e || {};
>   const r = e.random || (e.rng || qZ)();
>   if (r[6] = r[6] & 15 | 64, r[8] = r[8] & 63 | 128, t) {
>     n = n || 0;
>     for (let i = 0; i < 16; ++i)
>       t[n + i] = r[i];
>     return t;
>   }
>   return jZ(r);
> }
> async function iK(e) {
30161c30190
<   const t = () => e.model.get("spec"), n = () => e.model.get("temp_indexes"), r = pn().logger(), i = /* @__PURE__ */ new Map();
---
>   const t = () => e.model.get("spec"), n = () => e.model.get("temp_indexes"), r = yn().logger(), i = /* @__PURE__ */ new Map();
30163c30192
<     const d = globalThis.crypto.randomUUID();
---
>     const d = YZ();

so notably the uuid package implementation gets bundled in (i.e. to my knowledge there is no perf benefit from explicitly handling the fallback.)

I defer to you on whether you prefer to do something Math.random based, but the StackOverflow answer seemed to dissuade people from trying something like that (relevant part quoted below)

Note: The use of any UUID generator that relies on Math.random() is strongly discouraged (including snippets featured in previous versions of this answer) for reasons best explained here. TL;DR: solutions based on Math.random() do not provide good uniqueness guarantees.

Let me know what you think and we can either merge as is or I can implement your suggestion.

[frtennis1]

I rebased the fix on top of some of the latest changes - @domoritz if you get a sec, let me know if you have thoughts on my previous message

[domoritz]

Thanks for the update. Looks good. I restarted the CI so hopefully that passes now (seemed to have been a random failure).