Improvement: Mining event sending check

[hannibal002]

What

Somehow we send the data from every player all the time to Soopy server? This is definitely not intended.
Reported: https://discord.com/channels/997079228510117908/1316207755719348324

Changelog Improvements

• Added option to disable sharing mining event data. - hannibal2
  • Improved accuracy when multiple users share mining event data.
  • Shared data includes event type, start, and end times.
• Limited the "Mining Event Data can't be loaded from the server" error message to once in chat. - hannibal2

Changelog Technical Details

• Added option to send a chat message only once. - hannibal2

[CalMWolfs]

I dont like this change as not sending the events when the setting is off significantly reduces the data that is available for the people that use this feature or other projects that rely on this api, is there an actual reason to disable this behaviour?

[hannibal002]

Why should a user send this data to others when they don't actively benefit from it by displaying it?
See farming contest sharing, we only send the data when the user has the farming contest display enabled.

This also falls in the the gray-ish category about sending user data to a server, without opt out options

[CalMWolfs]

the difference with farming contests and this is that farming contests needs 1 person to send it every 5 days, this needs constant data. Instead if people really want to opt out of this there should be a new option for this.

[CalMWolfs]

We also had this discussion before afaik and thats when we made it always send but hide errors if you had it off. The problem this user is having is that the errors when posting (from ApiUtils not from MiningEventTracker itself) still show. The posting method in ApiUtils should just have a boolean for wether to post errors in chat instead

[hannibal002]

i dont like the idea of hiding technical errors ever. we can hide known reasons (like the unspecified http 500 error or empty result when we know that soopy api is overloaded/offline) though

[CalMWolfs]

i dont like the idea of hiding technical errors ever. we can hide known reasons (like the unspecified http 500 error or empty result when we know that soopy api is overloaded/offline) though

I feel like generally this is the case but every rule has an exception, and i think having the base of a feature off is a fair exception for hiding errors relating to that feature

[github-actions]

I have detected some issues with your pull request:

Body issues:
Unknown category: Bug Fixes in text: ## Changelog Bug Fixes

Please fix these issues. For the correct format, refer to the pull request template.

[hannibal002]

in this case, the base is no real base option, since opt out is independent.
we want to know what random technical problems might occur for every user that is sending data, even when they dont want to see the feature themselfes.

As well as this is a reminder for the user that they are still sending data even though they dont see the display active.

[CalMWolfs]

Fair enough

[github-actions]

I have detected some issues with your pull request:

Title issues:
PR has category 'Fix' which is not in the changelog. Expected categories: Improvement

Please fix these issues. For the correct format, refer to the pull request template.

[github-actions]

One or more Detekt Failures were detected:

• ChatUtils.kt#L95: Variable 'messagesThatAreOnlySentOnce' could be val.