extend buf handle size

[00k]

issue #31
主要改动：

1. tran_buf_pool的malloc函数增加factor参数，作为SOFA_PBRPC_TRAN_BUF_BLOCK_SIZE的系数
2. BufHandle的buffer大小改为不固定
3. WriteBuffer扩展时新分配的tranbuf大小按照指数增长（1k、2k、4k、...），直到最大值（32k）

[qinzuoyan]

我觉得将block_size放到block的头部位置（ref_counter之后）会更合理

[00k]

size放到头部对WriteBuffer是没问题的，但对于ReadBuffer有可能一个block被分到两个BufHandle里（message切分），这样BufHandle::data指向的是block的中间位置，这时候头部的size就没用了。

[qinzuoyan]

“BufHandle::data指向的是block的中间位置”——你理解有误，BufHandle::data永远都是指向block的起始位置，使用data+offset指向数据的起始位置。
我这边也在改进和优化，完成后我发出来看看。

[qinzuoyan]

优化已经完成，参见 0dbfbbd ， 8acfe52 和 1736cd3 。

主要优化点：

• 在block的隐藏头部中增加block_size字段；WriteBuffer扩展时新分配的tranbuf大小按照指数增长（1k、2k、4k、...），直到最大值（32k），在“降低大数据传输的延迟”和“避免memory浪费”之间进行权衡；ReadBuffer由于在多个buffer之间可以共享block，不会有memory浪费，所以在rpc_message_stream中接收数据时总是使用最大值（32K）。
• 设置tcp_no_delay，避免因为Nagle's Algorithm造成最后一个包的额外延迟。参见http://www.cnblogs.com/polymorphism/archive/2012/12/10/High_Latency_for_Small_Size_Entities_in_Table_Service.html 。但是这会使qps有少量下降，可以通过SOFA_PBRPC_TCP_NO_DELAY宏来选择是否开启该功能（默认开启）。

优化结果（通过运行test/perf_test/test_delay.sh测试得到）：

单条请求携带数据量	0.1KB	1KB	10KB	100KB	1MB	10MB
优化前延迟（单位微秒）	56	74	79942	31535	53439	124989
优化后延迟（单位微秒）	53	57	186	533	3782	25234

- 对于大数据，延迟降低明显 - 10KB的明显提升是因为设置了tcp_no_delay