> why we need it?

most of our subscribers will be RPC WS subscribers, so if there are too
many, nothing wrong with rejecting to subscribe.

however, consensus reactor must be the first to subscribe, since its
work depends on the pubsub package.

I've tried https://github.com/hashicorp/golang-lru/tree/master/simplelru today and here are
the results:

with LRU cache:

```
Benchmark10Clients-2                               50000             29021 ns/op         3976 B/op         105 allocs/op
Benchmark100Clients-2                               3000            363432 ns/op        36382 B/op        1005 allocs/op
Benchmark1000Clients-2                               500           2473752 ns/op       360500 B/op       10009 allocs/op
Benchmark10ClientsUsingTheSameQuery-2             300000              4059 ns/op          773 B/op          15 allocs/op
Benchmark100ClientsUsingTheSameQuery-2            500000              4360 ns/op          773 B/op          15 allocs/op
Benchmark1000ClientsUsingTheSameQuery-2           300000              4204 ns/op          773 B/op          15 allocs/op
```

without LRU cache:

```
Benchmark10Clients-2                      200000              5267 ns/op             616 B/op       25 allocs/op
Benchmark100Clients-2                      30000             42134 ns/op            2776 B/op      205 allocs/op
Benchmark1000Clients-2                      3000            552648 ns/op           24376 B/op     2005 allocs/op
Benchmark10ClientsOneQuery-2             1000000              2127 ns/op             462 B/op        9 allocs/op
Benchmark100ClientsOneQuery-2             500000              2353 ns/op             462 B/op        9 allocs/op
Benchmark1000ClientsOneQuery-2            500000              2339 ns/op             462 B/op        9 allocs/op
```

> How were you using the lru cache exactly?

I was adding a KV pair each time there is a match plus checking if
`lru.Contains(key)` before running the actual check (`q.Matches(tags)`).

```
key = fmt.Sprintf("%s/%v", query + tags)
```

query parser

use parser compiler to generate query parser

I used https://github.com/pointlander/peg which has a nice API and seems
to be the most popular Golang compiler parser using PEG on Github.

More about PEG:

- https://en.wikipedia.org/wiki/Parsing_expression_grammar
- https://github.com/PhilippeSigaud/Pegged/wiki/PEG-Basics
- https://github.com/PhilippeSigaud/Pegged/wiki/Grammar-Examples

rename

implement query match function

match function

uncomment test lines

add more test cases for query#Matches

fix int case

rename events to pubsub

add comment about cache

assertReceive helper to not block on receive in tests

fix bug with multiple conditions

uncomment benchmark

first results:

```
Benchmark10Clients-2                1000           1305493 ns/op         3957519 B/op     355 allocs/op
Benchmark100Clients-2                100          12278304 ns/op        39571751 B/op    3505 allocs/op
Benchmark1000Clients-2                10         124120909 ns/op        395714004 B/op   35005 allocs/op
```

124ms to publish message to 1000 clients. A lot.

use AST from query.peg.go

separate pubsub and query packages by using Query interface in pubsub

wrote docs and refactor code

updates from Frey's review

refactor type assertion to use type switch

cleanup during shutdown

subscriber should create output channel, not the server

overflow strategies, server buffer capacity

context as the first argument for Publish

log error

introduce Option type

update NewServer comment

move helpers into pubsub_test

increase assertReceive timeout

add query.MustParse

add more false tests for parser

add more false tests for query.Matches

parse numbers as int64 / float64

try our best to convert from other types

add number to panic output

add more comments

save commit

introduce client argument as first argument to Subscribe

> Why we do not specify buffer size on the output channel in Subscribe?

The choice of buffer size of N here depends on knowing the number of
messages server will receive and the number of messages downstream
subscribers will consume. This is fragile: if we publish an additional
message, or if one of the downstream subscribers reads any fewer
messages, we will again have blocked goroutines.

save commit

remove reference counting

fix test

test client resubscribe

test UnsubscribeAll

client options

[pubsub/query] fuzzy testing

do not print msg as it creates data race!