Fix: Update json backup tool for new features

[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

Update the json backup to include the newer features like status pages etc.

Resolves #1500
Resolves #3543
Resolves #3078
Resolves #2426
Resolves #2015
Resolves #1897

Type of change

Please delete any options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

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 generate no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

[louislam]

Welcome. Deprecated message could be removed along with this pr.

[chakflying]

As a start, I moved the backup generation code to serverside. In the process, I discovered that

• There is no centralized location to convert a Notification bean to JSON
• some of the sendXXXList() also returned the list (serialized or unserialized), but the list was never used. This is not useful as when I want the actual list I may not need to send it.

In the process I ended up refactoring these, hopefully it's not too big of a change

[louislam]

I think your direction is correct. It would be better to do this on server side.

[chakflying]

Functionality should be complete now, but such a big change I guess should have some tests added.

Basically I think having the entire application logic (particularly serialization and deserialization of data) in the socket-handlers is not the best design choice. As soon as there is some other feature that needs to reuse the logic (e.g. backups), it leads to code duplication, and is I think the main reason the backup feature was not maintained.

So I tried to move most of the database logic that I needed to the model files, and reuse it in both the socket-handlers and the backup code. But the backup of status pages still doesn't quite fit the existing logic so I added a new function for it.

IMO if we want to support an HTTP API in the future we may want to rethink this design.

[chakflying]

Not sure how to proceed, writing backend only test seems more difficult than expected. Don't know how to initialize the server properly in the test.

[CommanderStorm]

@chakflying
Could you add the following to the description? (if you think they are resolved)
Resolves #1500
Resolves #3543
Resolves #3078
Resolves #2426
Resolves #2015
Resolves #1897