将SocketSSLContext对象的创建职责交给end users

[thorneliu]

Is your feature request related to a problem? (你需要的功能是否与某个问题有关?) 从当前brpc代码支持ssl功能的实现上看，brpc框架本身承担了创建SSL_CTX对象的职责。 然而基于SSL本身的options非常的多，各个用户对于SSL的options要求也不一样以及同时SSL的版本也在不断更新等理由， 导致brpc支持ssl功能代码难以具备普遍性，无法适应新的变化

这个issue https://github.com/apache/brpc/pull/2251 就是一个直接的例子。

Describe the solution you'd like (描述你期望的解决方法) 我认为SSL_CTX对象的创建职责应该交给用户，rpc框架只负责SSL_CTX enable的情况下 做正确的handshake 和 TLS 读写功能即可：

client:

SSL_CTX* ctx = createSomeSSLcontext(); 
brpc::ChannelOptions options;
options.sslcontxt = ctx;
channel.Init(server.c_str(), load_balancer.c_str(), &options) != 0)

server:

SSL_CTX* ctx = createSomeSSLcontext(); 
brpc::ServerOptions options;
options.sslcontxt = ctx;
brpc::Server server;
server.Start(port, &options)

Describe alternatives you've considered (描述你想到的折衷方案) NA

Additional context/screenshots (更多上下文/截图) NA

[xuning97]

any progress in this issue?

[chenBright]

@thorneliu 看#2251 的实现，需要一个user SocketSSLContext和SSLHandshakeComplete回调函数才能支持吧。

[thorneliu]

any progress in this issue?

@thorneliu 看#2251 的实现，需要一个user SocketSSLContext和SSLHandshakeComplete回调函数才能支持吧。

大概是一个提供 sslpolicy和nonsslpolicy的连接实现；具体再sslpolicy里面 需要处理ssl handshake等内容

[thorneliu]

any progress in this issue?

Now it is just one proposal

[chenBright]

大概是一个提供 sslpolicy和nonsslpolicy的连接实现；具体再sslpolicy里面 需要处理ssl handshake等内容

将ssl逻辑都抽成SSLPolicy来是一个好主意。

虽然框架会基于目前框架的ssl设置提供一个默认的SSLPolicy，但是当用户需要自定义ssl handshake过程的时候，要这里逻辑写好，可能得去了解rpc实现（特别是Socket）。

然而基于SSL本身的options非常的多，各个用户对于SSL的options要求也不一样以及同时SSL的版本也在不断更新等理由， 导致brpc支持ssl功能代码难以具备普遍性，无法适应新的变化。

基于这个原因，自定义ssl handshake的复杂度应该是可以接受。