Avoid use of multipart.Part.FileName() to fix files API on Go 1.17

[benhoyt]

In Go 1.17 they changed part.FileName() to pass the result through filepath.Base() before returning, stripping off the directory component which is important for Pebble's files API. See https://golang.org/doc/go1.17#mime/multipart and golang/go@784ef4c.

Note that ReadForm() used in the tests also calls part.FileName() so we have to roll that ourselves too.

Incidentally, we'd had some discussion about this in the original PR: #25 (comment)

I had thought about using the filename field earlier, but originally decided against it because I know some clients strip off the path part of it (per the "SHOULD NOT" warning in RFC section 2.3 that you've quoted). However, Go does not, and we'll have a lot of control over the Python client (there's no multipart parser in the stdlib) so I think it's okay. I've updated the code to use "filename" -- it is simpler and cleaner.

Oh well, it's a fairly easy fix. :-)

This commit also runs Go 1.17's version of "go fmt", which adds some //go:build lines.

[benhoyt]

These are due to the new //go:build style build constraints being introduced (and go fmt adds them in Go 1.17). See https://go.googlesource.com/proposal/+/master/design/draft-gobuild.md

[jameinel]

This seems a significant difference in the looping. In the former we were iterating over everything in 'files' now we seem to be iterating just over the multipart but then not iterating over files.

(The old form looked like the data was something like:

{'blah': ?,
'files': [content, content, content],
}

But the new way we are treating it seems more like:
['blah', {'files': content}, {'files': content'}, {'files': content}]

I'm assuming that the test suite is passing so I'm wrong about something (I seem to recall some Python HTTP classes that would let you treat repeated headers as a single list.)

[benhoyt]

Yeah, I think you're assuming something wrong. The raw read-files response (before and after) is like so:

--01234567890123456789012345678901
Content-Disposition: form-data; name="files"; filename="/root/hi.txt"

Hello
--01234567890123456789012345678901
Content-Disposition: form-data; name="files"; filename="/root/bye.txt"

Bye bye
--01234567890123456789012345678901
Content-Disposition: form-data; name="files"; filename="/root/foobar.txt"

Foo
Bar
--01234567890123456789012345678901
Content-Disposition: form-data; name="response"

{
    "action": "read",
    "files": [
        {"path": "/root/hi.txt"},
        {"path": "/root/bye.txt"},
        {"path": "/root/foobar.txt"}
    ]
}
--01234567890123456789012345678901--

In the old code, we called multipart.Reader.ReadForm to loop over the multipart sections (files and response). In the new code, we do that loop ourselves and don't call ReadForm at all -- either way it loops over the files first, and then grabs the response at the end. Hope that helps.

[benhoyt]

@niemeyer I merged this relatively trivial fix with two approvals, but let me know if you have any concerns.