improve HeadersInit type

[Ethan-Arrowood]

This PR improves the HeadersInit type. The spec sorta gets this wrong (https://fetch.spec.whatwg.org/#typedefdef-headersinit) It only specifies record<ByteString, ByteString>, but record<ByteString, ByteString | undefined also works. I've tested it in multiple browsers and our implementation, and it works fine.

This allows me to pass an IncomingHTTPHeaders object directly to the constructor (which is valid for all other reasons except for this missing | undefined).

[codecov-commenter]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (e39a632) 85.54% compared to head (0a053f7) 85.84%.
Report is 65 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2373      +/-   ##
==========================================
+ Coverage   85.54%   85.84%   +0.29%     
==========================================
  Files          76       76              
  Lines        6858     6886      +28     
==========================================
+ Hits         5867     5911      +44     
+ Misses        991      975      -16     

Files	Coverage Δ
index-fetch.js	100.00% <100.00%> (ø)
lib/api/api-stream.js	100.00% <100.00%> (ø)
lib/api/readable.js	91.53% <100.00%> (ø)
lib/core/connect.js	80.00% <100.00%> (-1.25%)	⬇️
lib/core/request.js	92.38% <100.00%> (+5.29%)	⬆️
lib/fetch/body.js	97.68% <100.00%> (ø)
lib/fetch/global.js	100.00% <ø> (ø)
lib/fetch/index.js	86.39% <100.00%> (+1.19%)	⬆️
lib/pool.js	100.00% <100.00%> (ø)
lib/websocket/connection.js	89.15% <100.00%> (+0.13%)	⬆️
... and 3 more

... and 4 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[KhafraDev]

Technically webidl will handle any type we pass (null, numbers, objects, arrays, etc.) but we should be explicit in what types/values are expected (being what the spec tells us). Typescript's own DOM types do as much https://github.com/microsoft/TypeScript/blob/11a04ed9086e1e89cab970901b3496d5a67bcf59/src/lib/dom.generated.d.ts#L27983

[KhafraDev]

IMO the ReadonlyArray should be removed because it's not an expected value, I'm really not sure how that ended up there. Webidl will handle it, but probably not in an expected way, and we probably shouldn't encourage people to misuse it.

[Ethan-Arrowood]

I hear ya but we should match browser behavior. And honestly our types should match our implementation. If the spec does say to fail on undefined, and if our implementation doesn't fail on it either, I see little harm in adjusting the types so that we can avoid an unnecessary @ts-expect-error

[KhafraDev]

If you pass undefined as the value it'll get serialized to "undefined". It'll only lead to unexpected behavior. Plus the type, if we're following webidl, would be something similar to [any, any][] | Headers | Record<any, any> which is less explicit and less useful than stricter typings.