CLI: Replace '127.0.0.1' with 'localhost'

[SirLouen]

Closes #3132

The idea is to switch from 127.0.0.1 to localhost for the reasons stated in that ticket (mainly WSL2 compatibility out of the box)

This PR is already passing the cli tests, but I've been looking into the whole repo and it appears that the 127.0.0.1 is deeply engrained into the thing.

Still, I'm unsure why it was chosen over localhost so I would like hear more about this before trying to fix the 100+ coincidences of this in the code

[adamziel]

@SirLouen Thank you for contributing this! I'm not aware of any fundamental reason why it's one and not the other. I remember we've had some issues where "127.0.0.1" worked when "localhost" didn't (and vice versa!) with the dev server, but not with Playground CLI. @brandonpayton likely remembers some details around that.

That being said, I wonder if by preferring localhost, we need to bind to both 127.0.0.1 (ipv4) and ::1 (ipv6), and what are some perils of doing that, e.g. we'd likely have to fail if the port isn't available on either of these IPs, and I wonder what else.

[adamziel]

Also cc @wojtekn – any thoughts from Studio perspective?

[wojtekn]

@adamziel looks good. It makes it closer to Studio implementation as Studio already uses localhost as the default site URL.

[SirLouen]

@adamziel should we override whole 127.0.0.1?
I wonder what production testing conditions we could establish (apart from me running from my WSL2 instance).
How is this running in playground.wordpress.net?

[adamziel]

@SirLouen playground.wordpress.net is a mostly static website, it doesn't rely on CLI flags.

should we override whole 127.0.0.1?

If we go for localhost, we may need two binds: to 127.0.0.1 and to ::1. I've just experienced an issue with localhost yesterday where Safari connected fine, because it resolved localhost to 127.0.0.1, but Chrome couldn't connect, because it tried ::1 and there was no server running on that IP.

[SirLouen]

@adamziel I've been thinking about the issue and got to a new conclusion

Why we dont avoid hard coding the host and we add a host binding with a default bind just like the port?

This way I could go further and bind to --host 0.0.0.0 on CLI this way I would not need to hard tweak WSL2 to make this work.

Playground CLI as it is right now is unusable by Windows devs out of the box, and is a little headache to make it work. After testing in a new profile, I noticed that just adding localhost was insufficient for Windows hosts, and the inability of binding to 0.0.0.0 forces too much tweaking into WSL2.

My ultimate purpose is to abandon Docker for manual testing. I'm elaborating on this on my next training program for the test team.

What do you think?