rpk start: add tests

[0x5d]

Make rpk start testable by injecting the redpanda.Launcher instance instead of creating it when the command runs, allowing for mocking it and recreating various scenarios.

Fix #213

[emaxerrno]

@0x5d this is more of a discussion, but what about other commands.

Can you describe what injection points are left.

I imagine

1. Environment
2. Filesystem
3. Commands
4. Plugins
   4.1 Actual commands/ cat | exec | tee / etc
5. Custom per OS extensions

would all basically be under different interfaces

[0x5d]

@senior7515 so for rpk start (reposting here from Slack):

Environment: covered.
FS & actual commands: used by the check & tune steps in ‘start’. They're not covered by these tests yet.
Per-OS extensions: rpk start is itself OS-dependent (only built for Linux).

[0x5d]

@senior7515 can I merge this?

[BenPope]

The changes seem fine. I didn't review the tests.

[BenPope]

You could have a test for --overprovisioned flag overrides config overprovisioned: false ;) #304

Also, there are other flags, like node_id, smp, memory, etc.

[0xdiba]

LGTM pending Ben's comments.

my 2 cents, probably out of scope for this PR:
I can't help but wonder how we could make configuration testing easier. Having tests for every flag to verify that Get value from env if not provided through cli works should be tested centrally in some way and as a whole for the configuration 🤔

[0x5d]

LGTM pending Ben's comments.

my 2 cents, probably out of scope for this PR:
I can't help but wonder how we could make configuration testing easier. Having tests for every flag to verify that Get value from env if not provided through cli works should be tested centrally in some way and as a whole for the configuration thinking

Yeah. Ben and I were discussing that in a previous PR. The config.Manager api & initialization needs to change to account for these different config sources.
But I still think that there should be tests at the outermost layers (i.e. commands) checking that the command actually does the right thing regarding config source hierarchies and parsing.

[0x5d]

You could have a test for --overprovisioned flag overrides config overprovisioned: false ;) #304

I will fix this in another PR :D

Also, there are other flags, like node_id, smp, memory, etc.

Yeah, but these don't need to be parsed and checking them is harder, since they're not persisted but passed to redpanda directly. I think to effectively test them it has to be with integration tests.