Fix HTTP test port race and self-request origin

[ChihweiLHBird]

Summary

Fixes flaky HTTP integration test startup caused by a test harness port race.

The harness previously selected a port by binding localhost:0, reading the assigned port, dropping that listener, and later launching spin up --listen 127.0.0.1:{port}. In parallel test runs, another process could claim that port before this Spin instance bound it. The old readiness check only proved that something accepted TCP connections on the port, so a test could accidentally send requests to the wrong Spin app and see a spurious 404.

Change

Production code

• Track the actual bound HTTP listener address and use it for self-request origin setup.

Test framework

• Start Spin with --listen 127.0.0.1:0, then parse the actual bound port from this Spin process's startup output.
• Report early Spin startup failures with stdout/stderr.

Why the server change is needed

After the test harness switched to 127.0.0.1:0, HttpServer::listen_addr could remain 127.0.0.1:0 even though the actual listener was bound to an assigned port. Self requests must use the real bound address, not the configured :0 address. The server now stores listener.local_addr() after binding and uses that address when configuring SelfRequestOrigin.

For in-process tests, InProcessSpin builds a server and drives handle() directly without calling serve(), so no socket address is recorded. That path falls back to the configured listen address.

[itowlson]

I'll defer to @rylev on the test stuff, but I'd like to understand how often we are seeing port race failures - I don't think I've ever seen one myself. Unless you're being actively affected by them, I would tend to be conservative with changes.

I can see the issue with self-requests though. So we probably need to fix that and if the rest of it comes along for the ride well fair enough.

[itowlson]

Wait, don't we know whether it's printing JSON or plain text?

[ChihweiLHBird]

There was a test I added in the previous PR for testing JSON output, and all other tests are plain text. I can update the test code to force every test to output JSON, which is easier to handle. How does that sound?

[itowlson]

I was thinking more that we would be able to know when calling parse_serving_port whether the output was set to JSON. But maybe that info is buried in some Command arg that appears only in a callback somewhere and is inaccessible. It's fine to leave this as is.

[ChihweiLHBird]

@itowlson Thanks for the feedback! Actually, I saw more than once impact of this issue, sometimes it's very implicit, shown as 404 not found error, when a test code hits another test spin instance which doesn't have the expected path.

[itowlson]

I saw more than once impact of this issue, sometimes it's very implicit, shown as 404 not found error, when a test code hits another test spin instance which doesn't have the expected path.

Interesting. If it's happening that often, I'm surprised we don't get a lot more flakes in CI - I mean, yes, we do get flakes, but if they show up in manual testing then I'd expect them to absolutely wreck CI, which runs about a gazillion times on every PR. But of course we'd want it to be correct anyway!

[ChihweiLHBird]

I saw more than once impact of this issue, sometimes it's very implicit, shown as 404 not found error, when a test code hits another test spin instance which doesn't have the expected path.

Interesting. If it's happening that often, I'm surprised we don't get a lot more flakes in CI - I mean, yes, we do get flakes, but if they show up in manual testing then I'd expect them to absolutely wreck CI, which runs about a gazillion times on every PR. But of course we'd want it to be correct anyway!

Actually, I saw that from one CI run in my another PR and started investigating into it. I didn't catch it locally