Hello,
this PR aims to tackle one problem I had: streaming the output of a program while it is running over HTTP, similarly to the Github/GitLab CI "live" screens.
In fact, the goal is to perform a request to the server with cURL inside a gitlab-ci job, and see the output unfolds as the program is executed:

              web browser----------    ------------> -------------------| CLIENT |                  |  GitLab CI job  |----------   <------------  -------------------               streams the     |              ∧                  output       |              |                               | executes     | prints the                               |              | output                               |              | "live"                               ∨              |                             -------------------                             |       cURL      |                             -------------------                              |               ∧                              |               | streaming                              | HTTP          | (chunked                              | query         | transfer)                              |               | of stdin                              |               | and stdout                  spawns      ∨               |-----------  <------------   --------------------| program |                  | tiny-http server |-----------   ------------>  --------------------               sends stdout               and stdin in                 a pipe

Without this patch, the program executes in its entirety, and the output is sent all at once
once the pipe where the program writes its output is closed.

To achieve that goal, I submit two "sub-features":

• The ability to disable buffering insideResponse objects with theResponse::with_buffered method.
  Enabling this will force the transfer encoding to beTransferEncoding::Chunked and will ask the
  chunks encoder to flush to its underlying writer on every write.
• To get "instantaneous" write, disabling buffering in the chunks encoder is not enough, as the underlying
  writer returned when callingServer::recv() (ClientConnection.sink) is in fact a BufWriter wrapping
  the "real" output. Thebuffered_writer option inServerConfig, when set to false while instantiating
  a new server, omits the BufWriter to write to the TcpStream withotu any buffering. The cost of that
  abstraction is thatClientConnection.sink now boxes the writer to be able to choose between
  BufWriter<RefinedTcpStream> orRefinedTcpStream dynamically, which means there is now one additional
  pointer deference. I do however expect the performance impact to be small as this pointer is then stored
  in anArc<Mutex<>>, and I think locking/unlocking the mutex should be more costly that deferencing the
  pointer.

I expect this to decrease performance when sending big files, which is why these two sub-features are disabled
by default, and must explicitly be opted-in (by calling thewith_buffered method for the first, and by
instanciating the server with thebuffered_writer setting for the second).

Also note that the current iteration of this work breaks the current ABI, as it updatesServerConfig to
add thebuffered_writer option, andServerConfig was already exposed through theServer::new function.