Fix: Incorrect radius error & retry handling

[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

Fixes #3486

• Adds a dockerfile for setting up a test radius server
• Propagate the radius error, instead of setting the bean to down directly, to work with retries

While fixing this bug, I found 2 annoying issues with the node-radius-client library:

• The library has a built-in retry mechanism, and defaults to 3 retries. A bug in the library also prevents me from disabling this retry mechanism. This would interfere with our own retries and timings. For example, if you set our beat interval to 20 seconds with no retries, the library would retry on its own 3 times, which would lead to a real interval of ~60 seconds. To mitigate this, I have set the library's retry to the minimum of 1, and halved the connection timeout. This still takes much longer than 20 seconds for some reason, but it's the best I can do.

• The library uses Math.random to generate a random port for connection instead of getting an available port😅. This leads to random BIND EACCES errors if the port is occupied.

As discovered before, the repository for node-radius-client was deleted or set to private, so there is no place to report these issues. We need to think about forking the library or finding a more reasonable alternative.

Type of change

• 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]

This still takes much longer than 20 seconds for some reason, but it's the best I can do.

This is actually my concern of #3072, because the previous beat have not finished yet and the next beat started.

The library uses Math.random to generate a random port for connection instead of getting an available port😅. This leads to random BIND EACCES errors if the port is occupied.

Generating a random port sounds horrible.

I checked the code on npmjs.org, it is not obfuscated and the license is MIT, I think we can copy this into Uptime Kuma, or create a new npm package based on this later.

https://www.npmjs.com/package/node-radius-client?activeTab=code

[chakflying]

I see your point, both situations aren't ideal. I suppose there is no way to guarantee the heartbeat will terminate in the given interval for external libraries.