Add support for un-managed content (std::string_view) in http reply object

[sumeetchhetri]

@nyh, I have closed the earlier PR due to all the valid points raised from your side.
Instead of changing the core sstring structure, here the http reply object has been updated to accommodate un-managed strings.

[nyh]

I don't understand how an "un-managed" (i.e., reference) reply can work. The application generates this reply, and hands it to the HTTP server - but doesn't know exactly when the HTTP server will be done with this reply. It might need to do a lot of TCP work before it finishes to transmit this reply. So an "unmanaged" reply only makes sense if your reply is a constant string that can never be deleted. Is this your use case?

If, on the other hand, the problem is that your application builds a sstring and now wants to use it as the reply, the solution is not to pass a reference - it is to std::move the sstring into the reply. You don't need any new code for this.
If (and I'm just raising wild possibilities here, I don't know what is actually your problem), your application built an std::string, not seastar::sstring, then indeed we have a problem - unfortunately std::string doesn't offer any way to "release" its content so it can be "moved" into a seastar::sstring. This is what #634 is about - the existance of our "sstring" type is indeed not good, it would have been better if we used std::string everywhere.

Another thought:

A string reply (never mind if it's std::string, seastar::sstring, std::string_view, etc.) is really bad for long replies - it requires creating the entire reply in memory, and even worse - that the reply is in a single contiguous allocation. A better interface (that I believe we already have?) is a reply stream. We can easily create a stream implementation over an std::string, so this stream owns the std::string and deletes it when the stream ends. That will make sending a long std::string zero copy.

[sumeetchhetri]

Probably not able to explain correctly, this is needed if you have for eg, an extern "C" interface. Refer this for details, Imagine there is a application framework in C which needs seastar as a backend server engine, it passes a string to seastar (const char*/len) and takes care to clean it up on the next request (thread local here), this is not only about performance but more to do with the interface boundary, std::move would have been appropriate had it been within c++ only, I am open to suggestions here.

[nyh]

Can you please consider my reply stream idea? Instead of being a seastar::string the reply can (this is already supported in the code, IIRC) a function which can write into an output stream. This function can be lambda which holds the char* you want it to hold. As an added bonus, it can also free() it when it ends instead of waiting for some later time to do it.
This approach will have some small overhead for this extra function object, but will not copy the reply string so it's beneficial if it's long.

[sumeetchhetri]

Thanks @nyh, let me try the stream approach.