Checking for devtools config file for opt out

[eliasyishak]

This PR will make sure that when the config file for package:unified_analytics is being created the first time, it will check in the devtools config file for previous opt out status. If the user has already opted out in the past but haven't interacted with package:unified_analytics yet, then it will pass that information and opt out the user from package:unified_analytics collection.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[christopherfujino]

So here "legacy" doesn't necessarily refer to the analytics instance it's going to, but an implementation of analytics that predates package:unified_analytics, right?

And therefore, we will need to maintain this code in perpetuity?

[eliasyishak]

Couldn't it mean both? Currently devtools has their own implementation for analytics while it also sends to a different GA instance.. is that what you mean?

And yes, we would maintain this. It only runs the first time package:unified_analytics is run on a developers workstation though

[christopherfujino]

This looks good, but I'll defer approval to Kenzie

[kenzieschmoll]

i see this is the same logic for other tools with legacy opt in / opt out files, but why assume they are opted out if we can't read the file? Seems like instead we should assume that they haven't answered the question as to whether they want to opt in or not, and then we can ask them

[eliasyishak]

That's a fair question, I think we wanted to approach this with a more conservative approach. I was imagining a developer who thought they were opted out in the past, somehow ended up with a corrupted file, and now gets prompted again... they may dismiss it thinking it was bug and now we're collecting their data

I'm not opposed to swapping out this logic, just wanted to highlight that edge case

[kenzieschmoll]

I would think that if a user opted out once, they'd opt out again when prompted. The user set I'd be worried about dropping are the users who have opted yes, and then somehow their file gets corrected, and now we opt them out instead of asking them again, which would show up as a drop in our usage that could be due to the logic here.

I would guess the corrupted file case is pretty rare though, so maybe this isn't as big of a risk.

[eliasyishak]

I would guess the corrupted file case is pretty rare though, so maybe this isn't as big of a risk.

I have a separate PR that is out that will allow us to track how many times we run into these catch blocks so that should help answer if this happens often in the wild

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:unified_analytics	5.8.1	ready to publish	unified_analytics-v5.8.1
package:cli_config	0.1.2	already published at pub.dev
package:extension_discovery	2.0.1-wip	WIP (no publish necessary)
package:graphs	2.3.2-wip	WIP (no publish necessary)

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.