feat(repeater): refrain from utilizing non-standard ports

[lsndr]

BREAKING CHANGE: Remote repeater scripts are deprecated and no longer supported. Instead, please utilize the local scripts with the following command:

bright-cli --id <id> --token <token> --scripts '{"example.com": "./hmac.js"}'

closes #419

[derevnjuk]

The event listeners have nothing in common with each other. Let's inline their types to make it more cohesive.

Additionally, if you're not interested in the return value, declare the return type as unknown, this is the more user-friendly approach. Also, get rid of redundant wrappers, such RepeaterServerReconnectionFailedEvent

For details please refer to the example below:

requestReceived(
    handler: (request: RepeaterServerRequestEvent) => RepeaterServerRequestResponse | Promise< RepeaterServerRequestResponse >
  ): void;

  reconnectionFailed(
    handler: (error: Error) => unknown
  ): void;

[lsndr]

Done.

But I preserved void type for handlers which are not supposed to return anything. It seems to be more clear from handler's contract perspective. If I used unknown it would mean that handlers expect some data to be returned, that further will be processed. But with void it clearly says that no data is needed to be returned

[derevnjuk]

If I used unknown it would mean that handlers expect some data to be returned, that further will be processed.

You already handle the never type silently, hiding these details from the public API by using the void type.

Avoid using the void return type for callbacks when the return value will be ignored or handled (e.g. the never type). Instead, use unknown to explain clearly that you are not interested in the return value, regardless of what it might be, and gracefully handle all cases.

Anyway, you can keep it as for now, since this is part of internal API.

[lsndr]

Avoid using the void return type for callbacks when the return value will be ignored or handled (e.g. the never type). Instead, use unknown to explain clearly that you are not interested in the return value, regardless of what it might be, and gracefully handle all cases.

I think I don't fully understand what benefits unknown gives us in such cases.

unknown exactly says that i'm interested in returned value, but not in it's type. void says that it doesn't expect any value to be returned, so it won't be processed even if returned

[derevnjuk]

, so it won't be processed even if returned

However, you do. You silently handle the never, is not it so?

[lsndr]

Actually yes, but that's an implementation detail which in combination with void type will not happen

[derevnjuk]

These are not implementation details. Such "details" represent the post- and pre-conditions of any interface. Using the void here could potentially result in incorrect inheritance, contract and LSP violations.