feat: .url property on response objects

[SgtPooki]

Created based on mention from @achingbrain at #4 (comment)

After #5 we will have the .url property on responses that is the canonical URL for the requested resource.

With this PR the user can request the same resource via multiple URL formats. Should we be rewriting this URL to turn, for example, subdomain gateway requests into ipfs:// URIs?

I think we should absolutely be setting the canonical URL to the protocol we want to be natively supported in the browsers in the future. Which means, .url should always be a ipfs:// or ipns:// url.

[SgtPooki]

Looking at this again, i think we would be restricted to what gateway-conformance or specs require. I don't think there is any guidance currently on redirects to specific url formats.

[SgtPooki]

Helia WG discussion:

• Maybe it should just be http:// so it works for anyone, not just those with ipfs-desktop or other ipfs:// support.. for max compat and share-ability
  • I believe this is currently what we're doing.

@lidel do you have any thoughts here? I'm debating closing this because I am not sure that we still need to do this?

[lidel]

unsure how often people inspect response.url. i only checked it to tell if automatic redirect occurred, not sure if there is any other use case?

in verified fetch, it seems to be internal thing Alex had to implement to make UnixFS directory path normalization to work on inbrowser.link (#5), right?

My intuition is:

• prob. ok to keep as is, but keep this issue open until better UX is requested by users?
• if we want to improve DX, .url should follow whatever notation was passed to fetch (this way everyone will get what they expect):
  • if https://cid.ipfs.example/dir was passed, redirect occurred, and .url is https://cid.ipfs.example/dir/
  • if https://example.com/ipfs/cid/dir was passed, redirect occurred, and .url is https://example.com/ipfs/cid/dir/
  • ipfs://cid/dir was passed, redirect occurred, and .url is ipfs://cid/dir/