enhance logs functionality to handle build stage log - #48

There're several kinds of containers in a Function pod:

• the function container whose name is just function
• the dapr sidecar container
• the knative sidecar container

Normally we only output logs from the function container is enough. This is why we set container name to function in 21bea4c#diff-5c7fb0ae4b5f3afe942a2e3eed411e5a10ffff3e1dccbbf969947d98b79d60d7L54

If the user needs to view logs from dapr sidecar or knative sidecar, he can specify container name. If container name is not specified, the default one function will be used.

So we needn't to add a loop here to iterate all containers

The goto serving logic here is to fetch serving logs continually after the build phase ends.

But I think we can make it simpler by removing the 'goto serving' logic:

• If there is builder CR exists, just continually fetch build logs by adding -f option. The builder CR will not be deleted if the build fails and will be deleted when the build succeeds.
• If there is no builder CR, and there is serving CR. This means the build is successful, so we only need to fetch serving logs
• If there is no builder CR and no serving CR either, means this is in between the build and serving phase, and we needn't fetch any logs. And we needn't wait for the serving pod to be started either. The possibility of this scenario is small.

In short, we only need to fetch logs from the currently existing pod's function container by default.
No need to wait for the serving pod to up and running.

Yes, I totally agree with you! I thought too much before.

Thanks for your review!