Feat: Use UptimeCalculator for PingChart

[chakflying]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Depends on #4267
Depends on #4406
Resolves #2251 as the jitter is now "printed"

Update PingChart to use data from the new UptimeCalculator.

• Use 3 line charts to show the min, max and avg ping together for better visualization
• Avoid modifying heartbeatList, and instead store the received data in a separate data structure.
• With this method, there seems to be no easy way to show the maintenance period. How should we handle this? Adding another column in the stat_minutely tables seems wasteful.

Type of change

Please delete any options that are not relevant.

• User interface (UI)
• New feature (non-breaking change which adds functionality)
• Breaking change (a fix or feature that would cause existing functionality to not work as expected)

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• My changes generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

[chakflying]

Realized the stat_daily data is not really useful for the chart. There would only be 7 data points for the 1 week chart, and there would be no meaningful information about when up/down events occurred.

Ideally we'd have a stat_hourly covering a couple of weeks. Currently going from minute to day is a 2 orders of magnitude increase, and one might say it's too big anyway. But doing this would also increase a bit of complexity, and I don't know if the data would be useful elsewhere.

[chakflying]

Rebased on master, did a quick test and seems to work okay. Still have a couple of issues:

• Will return value 0 even for monitors without ping value. Might need special handling for this
• No handling for maintenance periods

[louislam]

Depends on #4267

#4267 had been merged, for your info.

[chakflying]

@louislam have you thought about how to store past maintenance information? I'm leaning towards adding a new column in the stats tables, so that it's indexable. However, if we think about having many other values to keep track of in the future, it may be better to have an "extras" column, then json encode the values. {"maintenance": 10, "slow_response": 2}

[louislam]

Yes, I think it is a good idea to have a column for extra stats.

[chakflying]

Maintenance should now also be shown.

Branch will be rebased again once #4406 is merged.

[chakflying]

Also fixed a long standing issue where the ping line would get weirdly connected if the server was turned off for a while.

[CommanderStorm]

From my point of view, this is mergable. (tested and this works as intended)
@louislam would you like to review this too?

[CommanderStorm]

From my point of view, this is mergable. (tested and this works as intended)
@louislam would you like to review this too?

I guess that is a no on an additional review.
=> merging with junior maintainer approval
(if you still have something, I will obv. provide a PR as previously done ^^)