Auth-based, per-request permissions system

[gavin-norman-sociomantic]

Now we have a proper system of authenticating clients, it would be possible to add a permissions system, such that certain requests may only be initiated by certain clients.

An example of this would be very destructive operation like a request which deletes a whole storage channel, which the average client has no place performing.

[gavin-norman-sociomantic]

Another aspect which was discussed: it'd be nice to also have permissions based on an ip white/black list. For example, instances of apps running on a test server should not be allowed to read from but not write to live nodes. They will likely user the same auth key as the real apps, but can be distinguished by their ip.

[gavin-norman-sociomantic]

A simple initial idea for client-based permissions:

1. We add support for a set of action categories to be defined by the node. (e.g. "read", "write", "delete".) (These will need to vary by node, as some node types have different concepts of destructive requests, for example.)
2. Each request is assigned to one of these categories. (See https://github.com/sociomantic-tsunami/swarm/blob/v4.x.x/src/swarm/neo/node/ConnectionHandler.d#L65.)
3. The node's credentials file (or some config file) is extended to also allow specifying whether each client is allowed/disallowed to perform each action. (It may make sense to have the default permission always be "disallow", unless configured otherwise.)
4. When a client sends a request to a node, the node can look up the action category of the request and the permissions of the client, then decide whether to continue handling the request or return some error code.

[gavin-norman-sociomantic]

Another aspect which was discussed: it'd be nice to also have permissions based on an ip white/black list. For example, instances of apps running on a test server should not be allowed to read from but not write to live nodes. They will likely user the same auth key as the real apps, but can be distinguished by their ip.

I think this is a separate idea. I don't think the implementation would share much in common with the per-client / per-request permissions. Split to #166.

[gavin-norman-sociomantic]

It may make sense to have the default permission always be "disallow", unless configured otherwise.

This would be a major breaking change, though :D

[gavin-norman-sociomantic]

After some discussion, we decided to go for a super simple scheme, as follows:

• Store name of connected client and make accessible at the level of request handlers #169 enables request handlers in the node to get the name of the connected client.
• For very sensitive requests (e.g. RemoveChannel, Redistribute), we add a simple check that the client's name is "admin" and send an error status code, if not.

This approach addresses all of our current needs. We can extend it to a more complicated system, if we ever need one.

Nothing more to do here.