Rename agent/proxy package to reflect that it is limited to managed proxy processes.

[banks]

Rationale: we will have several other components of the agent that relate to Connect proxies for example the upcoming ProxyConfigManager component needed for Envoy work. Those things are pretty separate from the focus of this package so far which is only concerned with managing external proxy processes so it's not a good fit to put code for that in here, yet there is a naming clash if we have other packages related to proxy functionality that are not in the agent/proxy package.

Happy to bikeshed the name. I started by calling it managedproxy but managedproxy.Manager is especially unpleasant. proxyprocess seems good in that it's more specific about purpose but less clearly connected with the concept of "managed proxies". The names in use are cleaner though e.g. proxyprocess.Manager.

This rename was completed automatically using golang.org/x/tools/cmd/gomvpkg.

Depends on #4541

[mkeeler]

I think the automated refactor missed a few places:

agent/proxyprocess/process_windows.go
agent/proxyprocess/exitstatus_other.go

I suspect the refactor only considered files matching the correct build tags and those two are for windows.

[mitchellh]

This is fine with me. I generally don't like package names that span multiple words, I try to think more categorically like: does agent/proxy/process make sense? Then we could have agent/proxy/config etc. I don't know the answer.

But I'm not going to die on this hill and its fairly easy to change (once we figure out the tooling) later since its an internal package.

[banks]

I try to think more categorically like: does agent/proxy/process make sense? Then we could have agent/proxy/config etc. I don't know the answer.

Yeah I considered that and I much prefer the import path there but in those cases you end up with a more ambiguous package name in use: process.Manager. Actually that's fine but doesn't indicate it's related to proxy processes. A worse example will be agent/proxy/config which would just import as config.Manager by default which is super misleading. The import site can always alias them if it's ambiguous in context I guess but wasn't a clear naming win for me to require aliasing for good context later.

I'm also happy to change it if there is any amount of preference for that though.

[banks]

Good catch @mkeeler

[mitchellh]

Yep got it @banks no problem, I'm fine with this.