Add current-job api

[moskyb]

This PR: Exposes an API through the agent's job executor (aka "the bootstrap") that allows running jobs to mutate or introspect their own state.

This API currently exposes three endpoints:

• GET /api/current-job/v0/env to get the environment of the currently running job
• PATCH /api/current-job/v0/env to update the job's environment
• DELETE /api/current-job/v0/env to remove certain keys from the job's environment

On unix machines, this API is exposed via a unix domain socket, and on windows, TBD.

Still to do:

• Figure out how to serve the jobapi.Server on windows (probably a normal TCP port or something? UDSes are available on recent builds of windows, but we don't want to have to replay on that) we're going to do this in a separate PR
• Write tests for jobapi.Server
• Actually run the jobapi.Server from the job executor + do some manual testing that it looks all good
• Create a jobapi.Client thingy to allow other bits of the agent (and potentially other golang projects 👀) to use this API We're also going to do this in a separate PR (and potentially later on)

[DrJosh9000]

Some comments for you!

[DrJosh9000]

Hey! I wrote some more comments for you...

[DrJosh9000]

Maybe worth a comment mentioning the Linux-path-length-for-Unix-sockets problem?

[DrJosh9000]

🎉 🎉 🎉 🥳 🎊 🪩 🍕

A bunch of remaining comments are minor nits, I leave it up to you whether to apply, raise a follow-up, or ignore 🥺

[DrJosh9000]

[Something to think about] If this did return an error, is that worth logging?

[DrJosh9000]

[Suggestion] If the error is being dropped here (which is fine) then why not go s.httpSvr.Serve(l) ?

[moskyb]

if a func returns an err that i'm not tracking, i much prefer to have _ = mightFail(), as it makes my intentions clear - it shows that i know that this function might return an error, but that i explicitly don't care. happy to change either way, but it's a readability thing that i like

[DrJosh9000]

That's fair, and tend to agree that _ = to denote deliberately ignored errors is nice. I'm less used to it.

Though I think http.Server.Serve is a bit unusual in that it always returns a non-nil error.

[moskyb]

oh that's true, i hadn't realised that... i think we're probably still fine to ignore it though, unless you disagree?

[DrJosh9000]

Ignoring it is fine, with either syntax.

[DrJosh9000]

There should be a .gitignorefmt. I want to argue with this being at this spot in the file and in all caps, but it also isn't wrong?

[triarius]

Nice work! I have some early comments I want to get in.

[DrJosh9000]

I just discovered golang/go#33357, so this check might need skipping on Windows

[moskyb]

😭

[DrJosh9000]

I'm having trouble even calling os.Stat on the socket on Windows. But connecting to it is fine.

[DrJosh9000]

Here's what I ended up with in the client:

agent/jobapi/client.go

Lines 51 to 69 in 3f9c89d

	// Check the socket path exists and is a socket.
	// Note that os.ModeSocket might not be set on Windows.
	// (https://github.com/golang/go/issues/33357)
	if runtime.GOOS != "windows" {
	fi, err := os.Stat(sock)
	if err != nil {
	return nil, fmt.Errorf("stat socket: %w", err)
	}
	if fi.Mode()&os.ModeSocket == 0 {
	return nil, fmt.Errorf("%q is not a socket", sock)
	}
	}
	// Try to connect to the socket.
	test, err := net.Dial("unix", sock)
	if err != nil {
	return nil, fmt.Errorf("socket test connection: %w", err)
	}
	test.Close()