Allow downstream projects to programmatically run envoy

[arkodg]

Is your feature request related to a problem? Please describe.
I would like to import packages within this project to programmatically run envoy from another go process
so I can use this project to instantiate envoy sub processes during integration testing

Describe the solution you'd like
Ideally would like github.com/tetratelabs/func-e/internal/cmd to moved to github.com/tetratelabs/func-e/pkg/cmd

[arkodg]

@codefromthecrypt can you please elaborate on #419 (comment) if you still believe that is the better way of allowing downstream projects to consume the CLI rather than depending on the cmd package and its existing API ?

[codefromthecrypt]

I don't think you need to expose the entire package hierarchy in order to provide an api. Basically what I mean is to make a top-level api that only includes the functionality needed. That top-level type can defer to the internal code.

[arkodg]

this is a snippet of how someone might import func-e to spawn envoy

import (
	funcecmd "github.com/tetratelabs/func-e/pkg/cmd"
	funceglobals "github.com/tetratelabs/func-e/pkg/globals"
	funceversion "github.com/tetratelabs/func-e/pkg/version"
)
....
func FuncERunCmd(args []string) error {
	o := funceglobals.GlobalOpts{}
	o.EnvoyVersion = funceversion.LastKnownEnvoy
	o.Out = os.Stderr
	funcECmd := funcecmd.NewApp(&o)
	// Always use amd64 for now, since it is the only arch that consistently available in
	// https://archive.tetratelabs.io/envoy/envoy-versions.json. This is also done in e2e if we use
	// func-e as the Envoy runner.
	funcERunArgs := []string{"func-e", "--platform", runtime.GOOS + "/amd64", "run"}
	// Append args
	funcERunArgs = append(funcERunArgs, args...)
	return funcECmd.Run(funcERunArgs)
}

@codefromthecrypt are you referring to moving the bare minimum such as
cmd.NewApp and globals.GlobalOpts into api/ , if so, can raise a PR for it

[codefromthecrypt]

Sorry I don't mean move as it is clunky. I mean to design a proper api and use it. I'll put a sketch up as I think show > tell

[arkodg]

thanks @codefromthecrypt

[codefromthecrypt]

cool #434 is on a shared branch so feel free to use it or close it.

Main thing is the library approach should be able to control writers and things especially as that makes it testable. Also, except for emulation, I think you'll want to default to the real architecture vs choosing something besides GOARCH. Anyway, the main idea is to make a package and only poke holes as needed, make it idiomatic for go use as opposed to exposing the CLI mechanics directly. This is true even if tactically CLI mechanics are used!

Hope this helps