Notify users about tracking opt-in instead of forcing choice

[idea404]

This PR addresses the data-sharing opt-in that prompts user feedback in the current version of NEAR CLI. This opt-in prompt requires user input and complicates implementing NEAR CLI in CI pipelines in straightforward manner. (Further mentioned in #796)

The changes are:

• NEAR CLI now notifies the user of the possibility of opting in for data sharing. The setting is defaulted to false.
• User may opt in by running near track yes and opt out at any later time by running the same command with no as a parameter
• CI test is introduced to test this functionality
• These changes preserve previous tracking behavior that does not add an accountId to the data shared

Notification:

Enable tracking:

Disable tracking:

Wrong param:

[volovyks]

I'm sure that the amount of data that we receive will drop significantly. Nobody will explicitly tell the system that they want to share usage statistics. Was this design discussed with the product teamt? cc @AustinBaggio @TiffanyGYJ

As an alternative, we can add the near tracking enable/disable command but leave the prompt as it is. We will still recieve user statistics and people who write scripts will start them with near tracking enable/disable.

Another option - add --yes flag. Check how it is done in the npm init command.

[TiffanyGYJ]

This is a good point, thank you for bringing it up. For the near tracking enable/disable, will we auto-enroll them into enable or? cc @pkudinov

[idea404]

This is a good point, thank you for bringing it up. For the near tracking enable/disable, will we auto-enroll them into enable or? cc @pkudinov

@TiffanyGYJ new users are unenrolled by default. Users that already have the NEAR CLI carry their settings with them from the previous version.

We could also have users enrolled by default and adapt the notification. Both approaches are fine by me. We could also add to the message that account IDs are not coupled to the data, which could also help motivate data sharing.

cc: @thisisjoshford @dgorton

[volovyks]

I do not think that we should track users by default. Possible options are either ask and track/not track or do not track by default (I have described the downsides of this approach above).