Only disable analytics for Quarkus CLI dev or build command

[michalvavrik]

Summary

This PR does 2 things:

• disables analytics for remote dev mode as we waste time there (10 seconds, see daily builds)
• refactors workaround for TLS command that disables analytics just for itself

Right now analytics are send during build and DEV mode. In https://quarkus.io/usage/ and https://quarkus.io/version/main/guides/build-analytics#show-me-the-code Quarkus explicitly documents that:

• analytics are send in DEV mode
• you can look when analytics are send in io.quarkus.analytics.AnalyticsService#sendAnalytics:
  • I checked an they are also send for quarkus build command

This can change in the future and noone from QE team will check every one and then if that has changed. So until now we always set -Dquarkus.analytics.disabled=true unless explicitly disabled. Now it does matter when Quarkus CLI TLS command is used because that command reports unknown option for setting this system property.

What are our options:

• report this inconsistency in Quarkus project and do nothing till it's addressed (if it is addressed)
  • but that means reporting something that is not clear bug, just our incovenience; for example, Quarkus supports "CI" environment variable that allows to disable this behavior, but we would have to change all our Jenkins jobs / GH workflows
• only exclude TLS command
  • that is my favorite, because it isolates scenario that clearly doesn't need analytics but doesn't break anything
• do what this PR does - only disable analytics when really needed

Honestly, not sure what is best, I think one day someone will report that I slowed down CI, but on the other hand, doing what this PR does, we won't always disable analytics when not needed. Why should users always do that? It feels stupid to expect users to always add it and I don't believe they will. So closer to user case.

Update: I rerun related tests and this seems to disable analytics as expected.

Please check the relevant options

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Dependency update
• Refactoring
• Release (follows conventions described in the RELEASE.md)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• This change requires execution against OCP (use run tests phrase in comment)

Checklist:

• Example scenarios has been updated / added
• Methods and classes used in PR scenarios are meaningful
• Commits are well encapsulated and follow the best practices

[michalvavrik]

I think @rsvoboda is busy (after reading that next build arrived in my inbox) so I'll set @mjurc , but please @rsvoboda feel free to comment. We can always tweak things later.

[mjurc]

This looks good to me, thanks for the fix