feat: pull client functionality and CLI command

[anpep]

This PR isolates the pull functionality that was removed from the previous PR (#147) and introduces the following changes:

• Use a destination io.Writer instead of a local file path or io.Reader.
• Includes close to perfect coverage of the pebble pull command and client functionality.

Feedback appreciated!

[benhoyt]

We skimmed through this with Gustavo during our London mini-sprint, and it looks good. He's going to take one more pass before we merge.

[flotter]

I do not yet have the Go experience give any authoritative approvals. However, I deeply studied both the pull and push code, and compared the expectations of the daemon side, and it looks good for me.

The only observation, which I highlighted on the push PR, is the daemons ability to handle multiple files in a request, and the client side only ever requests a single file, which seems like a sensible starting point.

[anpep]

I do not yet have the Go experience give any authoritative approvals. However, I deeply studied both the pull and push code, and compared the expectations of the daemon side, and it looks good for me.

The only observation, which I highlighted on the push PR, is the daemons ability to handle multiple files in a request, and the client side only ever requests a single file, which seems like a sensible starting point.

Thanks for your feedback on both PRs!

[benhoyt]

@anpep Looking good -- no further comments. Could you also bring this one up to date, and maybe we can get it merged before too long as well? (Though I realize it'll conflict again with #147 if we merge that first.)

[benhoyt]

FWIW, this has been requested a few times, by @sed-i on the Observability team most recently.

[anpep]

I've brought this PR up to date. I'd like to receive feedback on this one, especially on the part where I handle response headers. I decided to write a simple headerToMap() function which converts a http.Header to a map[string]string. Note that the underlying type behind http.Header is map[string][]string (in order to handle multiple headers with the same name), but I wanted to retain the same type we use for RequestOptions:

type RequestOptions struct {
    // ...
    Headers map[string]string
}

type RequestResponse struct {
    // ...
    Headers map[string]string
}

[benhoyt]

Just the Headers field type change (as discussed) and some very nitty things to change.

[benhoyt]

One more tweak Header -> Headers, and also we need to merge from master and fix conflicts. Thanks!

[benhoyt]

Sorry to nitpick, but I think I'd like this called Headers plural to match the field name in RequestOptions (I've always found it weird that the net/http field name is singular anyway).

[anpep]

Sorry about the incomplete changes @benhoyt! I absolutely forgot we already merged push into master (:

[benhoyt]

Looking good!