feature request: websocket api including client and server

There are similar issues for client: https://github.com/libevent/libevent/issues/1548
And there is a minimal websocket server in master branch since commit e8313084f9e8b064433cb10eb9a79bf87407fab6, including 11+ commits after.

For websocket, we should think about how libevent would offer websocket.

• generate sec-websocket-key? requiers base64, used by client to generate, and server to validate.
• generate sec-websocket-accept? requires sha1, used by client to validate, and server to generate.
• handle websocket handshake? leave the sec-websocket-key / sec-websocket-accept for user code, or offer them in libevent?
  • IMO, libevent shouldn't offer base64 / sha1, user choose their own from mbedtls or openssl should be better.
• parse websocket frame? use bufferevent_filter_new with BEV_NEED_MORE is easy.
  • support mask? and custom fin, rsv, op, ...?
• build / make websocket frame?
  • support mask? and custom fin, rsv, op, ...?
• should 64-bits payload be supported?
  • if it's less than 2**16, libevent / user code can buffer such a small frame.
  • otherwise, libevent / user code should remember the mask key in the frame lifecycle.
• handle ping automatically?
• support custom extension?

IMO, if libevent choose to offer websocket, both client and server should be offered.

And when extra components were added in libevent, we should consider the quality. I never forget the issue in stackoverflow:

the extra components such as the http and dns servers suffered from bad implementation quality and resultant security issues

The comments were issued on 2012, and updated on 2017, and I don't agree it after a simple review for the http component I'm using.
However, we should consider for the extra component in libevent.

Start by reviewing the minimal WebSocket server introduced in commit e8313084f9e8b064433cb10eb9a79bf87407fab6 and the related client issue #1548. Evaluate the proposed handshake, frame parsing and construction, masking, payload sizes, extensions, and automatic ping behavior before defining a client/server API. Done means the scope and API are agreed and covered by implementation and tests.