v1.3.5

Support different IO Mod for http and websocket

IOMod	Remarks
IOModNonBlocking	There's no difference between this IOMod and the old version with no IOMod. All the connections will be handled by poller.
IOModBlocking	All the connections will be handled by at least one goroutine, for websocket, we can set Upgrader.BlockingModAsyncWrite to handle writting with one more goroutine and then avoid Head-of-line blocking on broadcast scenarios.
IOModMixed	We set the Engine.MaxBlockingOnline, if the online num is smaller than it, the new connection will be handled by single goroutine as IOModBlocking, else the new connection will be handled by poller.

The IOModBlocking aims to improve the performance for low online service, it runs faster than std.
The IOModMixed aims to keep a balance between performance and cpu/mem cost in different scenarios: when there are not too many online connections, it performs better than std, or else it can serve lots of online connections and keep healthy.

The websocket now also support std http server, and I got a better performance and lower mem/cpu cost than std in a simple load test. The example of using with std http server would be like this:

package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/lesismal/nbio/nbhttp/websocket"
)

func echo(w http.ResponseWriter, r *http.Request) {
	u := websocket.NewUpgrader()
	u.OnMessage(func(c *websocket.Conn, mt websocket.MessageType, data []byte) {
		c.WriteMessage(mt, data)
	})
	_, err := u.Upgrade(w, r, nil)
	if err != nil {
		log.Print("upgrade:", err)
		return
	}
}

func main() {
	mux := &http.ServeMux{}
	mux.HandleFunc("/ws", echo)
	server := http.Server{
		Addr:    "localhost:8080",
		Handler: mux,
	}
	fmt.Println("server exit:", server.ListenAndServe())
}