fix: service logs flag exclusivity

[christophercampbell]

Description

This PR changes service logs to check exclusivity on --follow and --num. To do this the default value for --num is set to 0. The underlying flag parser does not expose whether the flags exist on the command line

@tedim52

Is this change user facing?

YES

[tedim52]

Thanks for the contribution! Holding on merging anything till we resolve a release issue but will review in the meantime.

Although I feel-n and -f are compatible. IMO - the behavior with -n and -f set on service logs is, say -n=100, the command should retrieve the most recent 100 logs, and then after that continue to follow logs. That's actually the current the behavior with service logs - -n by default is set to 200 - so when doing service logs -f - the behavior is to get the most recent 200 logs - and then continue to follow. Do you think that behavior causes friction in anyway/if so can you tell me more about why? LMK what you think.

[christophercampbell]

The problem with -n > 0 is I could not find a way of determining the presence of the flag otherwise. The flag library does not expose the difference between a user supplying a value and the default value. So I could not figure out if user supplied -f and -n intentionally otherwise.

I do see your point about last N, then follow. But in that case it seems -n should be 0 by default anyway?

[tedim52]

ahh makes sense - do you think -n should always be 0 by default or only if -f is set?