Add 'server ID' config option

[corrideat]

Problem

We currently use variants of the same DB in various environments, such as production and staging. Doing this could result in issues with sending push notifications to unintended clients. At the same time, this setup could be beneficial for testing and debugging purposes.

The unintended notifications can result in issues such as a 'forked chain' error in the client, or less serious issues like unintended contract updates.

Solution

In order to address this, we could add a server_id or similar configuration setting to chel.toml, which is stored when a push notification client is stored, and then compared when loading clients from the DB. If a push client has a different server_id than what is configurd, it is simply skipped.

In addition, we can create a chel init command that generates a template chel.toml file to ease set up.

Other solutions

router DB engine

The issue can be avoided without any changes by using the router DB engine to keep the VAPID keys server-local. This solution is clean and effective, but requires using router and requires specific configuration that may or may not apply to some use cases.

Automatic server_id

Instead of a user-configured server_id, it could be automatically obtained from system information, such as the hostname or a machine fingerprint. This solution was discussed but disregarded because of the risk of false negatives (e.g., push notifications would stop working if system configuration changes) and false positives (e.g., the issue could persist when using exact templates to run different servers)

[taoeffect]

Nice! Let's go with the primary solution (not the ones under "Other solutions").

Also noting that the presence of this server_id is important enough to prevent chel serve from running if it's not there in chel.toml.