Rename Slave to Host

The role of a slave as a host for Factorio servers is not well reflected
in its name and has caused confusion among users.  Rename slave to host
to better reflect its role as a host of Factorio servers.

docs/writing-plugins.md

@@ -41,7 +41,7 @@ The usual guides for creating such packages apply.
 At minimum the `package.json` file must contain a version entry.
 
 A possible workflow for developing plugins is to place the plugin in a sub-directory of where clusterio has been installed, and rely on Node.js searching up the folder heirarchy for it to find `@clusterio/lib`.
-To add it to `plugin-list.json` so that it gets loaded use the `plugin add <path>` sub-command to either clusteriocontroller, clusterioslave or clusterioctl.
+To add it to `plugin-list.json` so that it gets loaded use the `plugin add <path>` sub-command to either clusteriocontroller, clusteriohost or clusterioctl.
 Note that it's important that the path starts with ./ or ../ (use .\ or ..\ on Windows).
 
 For a plugin the most important file is the `info.js` file.
@@ -157,7 +157,7 @@ The async init method is always called immediatly after the constructor, so ther
 ## Logging Messages
 
 The base plugin classes provide a winston logger for logging messages to the shared cluster log.
-For instances a copy of the log is also stored on the slave the instance is on.
+For instances a copy of the log is also stored on the host the instance is on.
 To use it, pass a string to one of the log levels functions, for example:
 
 ```js
@@ -209,7 +209,7 @@ For example in info.js:
 const libConfig = require("@clusterio/lib/config");
 
 class ControllerConfigGroup extends libConfig.PluginConfigGroup { }
-ControllerConfigGroup.defaultAccess = ["controller", "slave", "control"];
+ControllerConfigGroup.defaultAccess = ["controller", "host", "control"];
 ControllerConfigGroup.groupName = "foo_frobber";
 ControllerConfigGroup.define({
     name: "level",
@@ -314,7 +314,7 @@ For RCON, commands longer than 50 characters may end up being executed after sho
 ## Defining Link Messages
 
 You will most likely have to communicate with the controller or other instances in your plugin for it to do anything useful.
-For this there's a WebSocket communication channel established between the slaves and the controller that plugins can define their own messages to send over it.
+For this there's a WebSocket communication channel established between the hosts and the controller that plugins can define their own messages to send over it.
 This channel is bi-directional and all messages sent over it are validated with a JSON schema (see [this guide][guide] for an introduction to writing JSON schema).
 
 [guide]: https://json-schema.org/learn/getting-started-step-by-step.html
@@ -335,7 +335,7 @@ The Event constructor takes an object of properties that define the event, for e
 messages: {
     startFrobnication: new libLink.Event({
         type: "foo_frobber:start_frobnication",
-        links: ["controller-slave", "slave-instance"],
+        links: ["controller-host", "host-instance"],
         forwardTo: "instance",
         eventRequired: ["frobnication_type"],
         eventProperties: {
@@ -346,9 +346,9 @@ messages: {
 },
 ```
 
-This specifies an event that can be sent from the controller to a slave, and from a slave to an instance.
+This specifies an event that can be sent from the controller to a host, and from a host to an instance.
 It also specifies that the event must contain the property `frobnication_type`, with a string value in the data payload and that it may optionally contain a boolean `urgent` property.
-It will also be forwarded by slaves to a specific instance.
+It will also be forwarded by hosts to a specific instance.
 
 The following properties are recognized by the Event constructor:
 
@@ -361,17 +361,17 @@ The type of the message sent over the socket will have the suffix `_event` appen
 #### links
 
 An array of strings describing which links this event can be sent over.
-Direction matters, `"controller-slave"` means the event can be sent from the controller to the slave, but can't be sent back the other way, unless `"slave-controller"` is also present in the links array.
+Direction matters, `"controller-host"` means the event can be sent from the controller to the host, but can't be sent back the other way, unless `"host-controller"` is also present in the links array.
 
-The available endpoints are `controller`, `slave`, `instance`, and `control`.
-Controller talks with slave and control, and slave talks to instance.
-The full chain must be specified as the individual links in order for a message to travers multiple hops, (i.e., for a message to go from controller to instance it must have both `"controller-slave"` and `"slave-instance"` in the links array).
+The available endpoints are `controller`, `host`, `instance`, and `control`.
+Controller talks with host and control, and host talks to instance.
+The full chain must be specified as the individual links in order for a message to travers multiple hops, (i.e., for a message to go from controller to instance it must have both `"controller-host"` and `"host-instance"` in the links array).
 See `forwardTo` and `broadcastTo` for ways to forward an event to the next link in a chain.
 
 #### forwardTo
 
 Target to forward an event to.
-Can either be `"controller"`, to indicate a slave should forward it to the controller, or `"instance"`, to indicate it should be forwarded to the instances specified by the `instance_id` event property.
+Can either be `"controller"`, to indicate a host should forward it to the controller, or `"instance"`, to indicate it should be forwarded to the instances specified by the `instance_id` event property.
 This works by using a default handler for the event at the links that forward it.
 
 #### broadcastTo
@@ -379,7 +379,7 @@ This works by using a default handler for the event at the links that forward it
 Target to broadcast this message towards.
 A value of "instance" means the event will be broadcast to all instances downstream of the target it's sent to, but not back from where it came from.
 Currently, only "instance" is supported.
-This means that sending the event to a slave from an instance will cause it to be broadcast to all instances of that slave except for the instance it came from.
+This means that sending the event to a host from an instance will cause it to be broadcast to all instances of that host except for the instance it came from.
 
 #### eventRequired
 
@@ -394,7 +394,7 @@ This is equivalent to using the `properties` keyword in JSON schema, except that
 See [this guide][guide] for an introduction to writing JSON schemas.
 
 The forwardTo and broadcastTo can be combined such that specifying `"controller"` as the forwardTo value and `"instance"` as the broadcastTo value will cause the event to be broadcast to all instances in the cluster.
-For this to work, you will need to specify `instance-slave`, `slave-controller`, `controller-slave`, and `slave-instance` as the links.
+For this to work, you will need to specify `instance-host`, `host-controller`, `controller-host`, and `host-instance` as the links.
 
 Keep in mind when forwarding events that if the target an event is being forwarded to is not online, the event will be dropped.
 Use a request if you need a confirmation that the message was received.
@@ -410,7 +410,7 @@ For example, the following could be defined in `info.js`:
 messages: {
     reportFrobnication: new libLink.Request({
         type: "foo_frobber:report_frobnication",
-        links: ["controller-slave", "slave-instance"],
+        links: ["controller-host", "host-instance"],
         forwardTo: "instance",
         requestRequired: ["verbosity"],
         requestProperties: {
@@ -427,10 +427,10 @@ messages: {
 },
 ```
 
-This specifies a request that can be sent from the controller to a slave, and from a slave to an instance.
+This specifies a request that can be sent from the controller to a host, and from a host to an instance.
 The request data must contain the property `verbosity` with an integer number as the value, as well as the `instance_id` property (implied by `forwardTo: "instance"`) and it may also contain a boolean `special` property.
 It also defines that the response sent must contain a `report` property mapping to an array of strings.
-When received by a slave, it will also be forwarded to the instance specified by `instance_id`.
+When received by a host, it will also be forwarded to the instance specified by `instance_id`.
 
 The following properties are recognized by the Request constructor:
 
@@ -443,17 +443,17 @@ The type of the message sent over the socket will have the suffix `_request` app
 #### links
 
 An array of strings describing which links this request can be sent over.
-Direction matters; `"controller-slave"` means the request can be sent from the controller to the slave and the slave can reply to the controller, but the slave can't send a request to the controller unless `"slave-controller"` is also present in the links array.
+Direction matters; `"controller-host"` means the request can be sent from the controller to the host and the host can reply to the controller, but the host can't send a request to the controller unless `"host-controller"` is also present in the links array.
 
-The available endpoints are `controller`, `slave`, `instance`, and `control`.
-Controller talks with slave and control, and slave talks to instance.
-The full chain must be specified as the individual links in order for a message to travers multiple hops, (i.e., for a message to go from controller to instance it must have both `"controller-slave"` and `"slave-instance"` in the links array).
+The available endpoints are `controller`, `host`, `instance`, and `control`.
+Controller talks with host and control, and host talks to instance.
+The full chain must be specified as the individual links in order for a message to travers multiple hops, (i.e., for a message to go from controller to instance it must have both `"controller-host"` and `"host-instance"` in the links array).
 See `forwardTo` for ways to forward a request to the next link in a chain.
 
 #### forwardTo
 
 Target to forward the request to.
-Can either be `"controller"` to indicate a slave should forward it to the controller when receiving it from an instance, or `"instance"` to indicate it should be forwarded to the instances specified by the `instance_id` request property.
+Can either be `"controller"` to indicate a host should forward it to the controller when receiving it from an instance, or `"instance"` to indicate it should be forwarded to the instances specified by the `instance_id` request property.
 This works by using a default handler for the request by the links that forward it.
 
 #### requestRequired
@@ -480,7 +480,7 @@ Same as the requestProperties only for the response sent back by the target.
 ## Sending Link Messages
 
 Link messages are sent by calling the `.send()` method on the Event/Request instance with the link you want to send it over and the data to send.
-For `InstancePlugin` code the link to the slave is the `instance` itself, which is accessible through the `.instance` property of the `InstancePlugin`.
+For `InstancePlugin` code the link to the host is the `instance` itself, which is accessible through the `.instance` property of the `InstancePlugin`.
 The `.info` property of the plugin class exposes the data exported from the plugin's `info.js` module.
 In other words:
 
@@ -497,26 +497,26 @@ For the Request class the send method is async and returns the response data rec
 ### Handling connection events
 
 There are a few connection related events that plugins neeed to repsond to in order to avoid data loss and connection problems.
-The most important is the prepare disconnect for the link between controller and slave.
-This is signaled to `ControllerPlugin` classes via the `onPrepareSlaveDisconnect` hook and to `InstancePlugin` classes via the `onPrepareControllerDisconnect` hook.
+The most important is the prepare disconnect for the link between controller and host.
+This is signaled to `ControllerPlugin` classes via the `onPrepareHostDisconnect` hook and to `InstancePlugin` classes via the `onPrepareControllerDisconnect` hook.
 
 After the prepare disconnect the connection will be closed, which will result in pending requests and events being dropped.
 Plugins must respond to the prepare disconnect by stopping any processess it does that send events or requests over the link in question.
-This can be accomplished either through listening for the prepare disconnect hook, or by checking the `connected` property of the `SlaveConnection` class and `Slave` class on the controller and slave respectively.
+This can be accomplished either through listening for the prepare disconnect hook, or by checking the `connected` property of the `HostConnection` class and `Host` class on the controller and host respectively.
 For example the sending of an event from an `InstancePlugin` class can be stopped while the connection is not connected, not in the dropped state, and not in the process of discunnecting by using the following code:
 
 ```js
-if (this.slave.connected) {
+if (this.host.connected) {
     this.info.messages.frobnicate.send(this.instance, { foo: "bar" });
 }
 ```
 
 If the event or request needs to be sent to the controller it can be put into a queue stored on the plugin instance and sent out when the connection is established again.
-The re-establishement of the connection is  notified to plugins via the `connect` event to the `onControllerConnectionEvent` and `onSlaveConnectionEvent` hooks.
+The re-establishement of the connection is  notified to plugins via the `connect` event to the `onControllerConnectionEvent` and `onHostConnectionEvent` hooks.
 
-The second connection event which is of lesser importance to respond to is the `drop` connection event served through `onControllerConnectionEvent` for `InstancePlugin` classes and through `onSlaveConnectionEvent` for `ControllerPlugin` classes.
-This is raised when the connection between the controller and slave in question is lost, most likely due to networking issues.
-When in the dropped state the slave will keep trying to reconnect to the controller in order to re-establish it, and if successful no events or requests will be lost.
+The second connection event which is of lesser importance to respond to is the `drop` connection event served through `onControllerConnectionEvent` for `InstancePlugin` classes and through `onHostConnectionEvent` for `ControllerPlugin` classes.
+This is raised when the connection between the controller and host in question is lost, most likely due to networking issues.
+When in the dropped state the host will keep trying to reconnect to the controller in order to re-establish it, and if successful no events or requests will be lost.
 However while in the dropped state any requests and events sent gets queued up in memory until the connection is either re-established or the session times out.
 This means that if your plugin sends a lot of events or requests, they can end up being queued up in a buffer and sent out all at once the connection is re-estabished.
 To avoid this you should be throtteling and/or stopping your requests/events after `drop` has been raised, and continue back as normal when `resume` is raised.
@@ -557,8 +557,8 @@ const barMetric = new Gauge(
 barMetric.labels(String(this.instance.id)).set(someValue);
 ```
 
-Metrics are automatically registered to the default registry, and this default registry is automatically polled by the controller on slaves.
-This means that it's important that you place the definition of the metric at module level so that it's not created more than once over the lifetime of a slave.
+Metrics are automatically registered to the default registry, and this default registry is automatically polled by the controller on hosts.
+This means that it's important that you place the definition of the metric at module level so that it's not created more than once over the lifetime of a host.
 Since the metrics remember their values and would continue to be exported after an instance is shutdown, there's code at instance shutdown that removes all the values where the `instance_id` label matches the id of the instance shut down.
 
 For statistics you need to update on collection there's an `onMetrics` hook on both controller and instance plugins that is run before the metrics in the default registry are collected.