Currently, there are no clear guidelines for determining when to log messages and what category to give them. We need to address the following, to begin with:

• Distinguishing TRACE vs. DEBUG messages.
• What events should be logged with INFO messages?
• When actions fail:
  • When to throw an exception and when to log.
  • When to WARN vs. when to log an ERROR.

Memory management in a seastar application is a very important topic, as seastar applications are usually long running server applications that want to maximize the usage of memory as well as be resilient to memory fragmentation.
Add a section on this to the docs/tutorial.md based on the lessons we learned at ScyllaDB. In a nutshell: when large buffers are needed prefer storing data in a chunke

1. We should build the redis result directly, instead of building over the `query_result_builder.
2. For the lists commands, such as `lrange, we do not read all the clustering row of the paritition.

the rpc_server should have 2 seastar::ipv4_addr structs, one for http and one for rpc.

There should be no implicit addr 's in codebase. i.e.: :::0