Add label to specify debug tools container for debugging

[panitaxx]

I would like to submit a PR to be able to select a different image for the duct-tape (extra tools for debugging). Specifically in go if your image is built with alpine it does not work with skaffold debug.

Expected behavior

Being able to specify my own debug tools init containers

Actual behavior

Debug tools init containers are hard coded

Information

I have thought some possible ways of doing this:

1. via a flag. something like

`skaffold debug --debug-tools-image='go=gcr.io/myownregistry/go-debug:xyz'

Like this. It will affect all go images marked for debugging.

2. via a label.

spec:
  replicas: 1
  selector:
    matchLabels:
      app: models
  template:
    metadata:
      labels:
        app: models
        debugTool: "gcr.io/myownregistry/go-debug:xyz"
    spec:
      containers:
      - name: models
        image: models
        command: ["/dbg/go/bin/dlv","debug","--headless","--api-version=2","--listen=:56268","--log"]

3. Just disable the automatically adding an init container witth a flag

skaffold debug --no-init-container

In this case init-container is not added. User is responsible for creating the dbg volume, and adding an init container that contains the tools and that copies them into the dbg mountpoint.

[balopat]

Thanks @panitaxx for opening! I like the name debug-tools :)
I think this is a reasonable direction - WDYT @briandealwis?

[briandealwis]

Since you're already rewriting your pod definition to invoke Delve, and presumably your container includes dlv, perhaps debug should just skip the initContainer entirely.

[tstromberg]

@panitaxx - are you still thinking about writing a PR to address this?

[briandealwis]

debug will now skip transforms on pods with an existing debug.cloud.google.com/config annotation (#4027). We have a contribution for configuring alternative locations for the debug support images in #3945.

[panitaxx]

@tstromberg I am sorry but right now I can't do this PR. It also seems that the PR mentioned by @briandealwis address the spirit of this issue so I think it's ok to close it.