Added support to block/unblock keys

[kelindar]

This PR adds support to block or unblock keys. This can be done using emitter/keyban/ request.

The block list is replicated across the cluster and persisted to disk on each broker. In order to specify the directory, use the newly added dir parameter to the cluster configuration section.

[Florimond]

LGTM

[postacik]

Hi, did you implement this by adding a persistent blocked keys table? Can it have an impact on performance because of the necessary lookup for each publish request?

[postacik]

And what kind of key will be needed for this request?

[kelindar]

Hi, did you implement this by adding a persistent blocked keys table? Can it have an impact on performance because of the necessary lookup for each publish request?

Indeed, there will be an extra lookup on each publish/subscribe request, that's the reason for an extra caching layer. Performance impact is negligible in most cases, as the lookup over a list of 20K blocked keys takes about 100 nanoseconds.

// Benchmark_State/contains-8         	11535033	       104 ns/op	       4 B/op	       1 allocs/op

On the implementation, we actually now have an disk-persisted internal state which is replicated with gossip. This would allow us to implement shared global state with ease going forward (e.g. shared sessions, shared LUA scripts, ... ).

[kelindar]

And what kind of key will be needed for this request?

There's two keys in the request a secret key and the target key to block. The request payload looks like this:

Secret string `json:"secret"` // The master key to use.
Target string `json:"target"` // The target key to ban.
Banned bool   `json:"banned"` // Whether the target should be banned or not.

[postacik]

So that means I'll need the master secret key to ban or unban other keys.

Could it be useful to use a special permission for keyban requests?

r = Read, w = Write, s = Store, l = Load, p = Presence, b = Ban/Unban

[kelindar]

So that means I'll need the master secret key to ban or unban other keys.

Could it be useful to use a special permission for keyban requests?

r = Read, w = Write, s = Store, l = Load, p = Presence, b = Ban/Unban

We were just discussing this with @Florimond. Unfortunately we've ran out of permission flags (as the last one we reserved for x = execute). We could still do something with master + extend in order to make "extended master keys" which only apply for a channel, that would be an equivalent to your b permission.

But what are the use-cases you're thinking of? Currently I can only see the use-case where you might have manually leaked a key and want to remove it.

[postacik]

I can't think of any use case now. It just came to my mind when I first saw it.

It's logical to ban keys using the secret key if you create keys using the secret key.