Calling port() with a default port returns None unexpectedly

[TomPridham]

• Note that this crate implements the URL Standard not RFC 1738 or RFC 3986

Describe the bug
related to #28
This was an issue way back in 2014, but doesn't seem like it was ever really addressed.
I would expect calling port() on http://example.com to return 80. It is really confusing that it would return a None. It's even worse when you set the port explicitly http://example.com:80 and it still seems like it isn't working correctly because it still returns None.

I could update the docs to have an example of the port being ignored, but it seems like it would just make more sense to have port() actually return the port and do what is suggested in this comment

[valenting]

I would think the docs are pretty clear on this issue.

https://docs.rs/url/2.5.2/url/struct.Url.html#method.port

You want port_or_known_default. Do you feel like the docs are missing something?

Note that changing the behaviour of port is a breaking change, and not something we'd consider doing at the moment.

[link2xt]

Can you add another API that returns Some(443) for "https://example.com:443" and None for https://example.com?

I need to distinguish between these cases because when user scans a QR code, in the first case this is likely an HTTPS proxy URL and in the second case it is likely a normal URL that I want to offer to open in a browser:
deltachat/deltachat-core-rust#5980

As a workaround I will now try to look at .authority() and see if it ends in :443 when scheme is https (and :80 for http), but this seems to be really hacky.
EDIT: does not work as default port is also removed from .authority().

[link2xt]

Another way to fix this would be to add an option to ParseOption to disable default ports.

[link2xt]

As a workaround I now replace http:// or https:// with foobarbaz:// before parsing. This disables all sort of normalization for ports, also does not add / path when the path originally does not exist.