If log capturing fails, consumers have no way to learn about it

@karolz-ms is already working on this.

Since Sep 9, 2024.

### Problem description
In DCP, serving logs for a resource (Executable or Consumer) follows pretty much the same pattern:

1. A request for logs for resource named "X" comes.
2. DCP API server checks if the logs for that resource are already being captured. If not, start capturing them into a temporary file. Executables start capturing logs automatically on startup, but Containers capture logs on demand.
3. For every new request to stream logs, DCP creates a response stream and starts pumping relevant logs to the client.

The problem is, if anything goes wrong with the process of capturing logs, we currently do not do anything. The temporary file with log data will simply stop getting any updates, and clients will not be notified that anything is wrong.

### Desired behavior
When log capturing for a resource fails

1. Existing in-flight requests should be ended with a failure
2. The next request should re-try log capturing from scratch. Depending on the type of resource this may or may not be possible. If log capture re-try is not possible, the request should fail immediately. Otherwise, an attempt should be made to re-capture and the client should get the result of this (fresh) attempt.