Support for non-seastar managed strings

[sumeetchhetri]

Add support for sstring instances that refer to existing non-managed strings(std::string, std::string_view, const char*[size_t])
This is required if we already have a std::string or a c string which needs to work with seastar sstrings, instead of copying the entire string we just want seastar to use the same with zero copy. The lifecycle of the string would be managed by the caller application.

[sumeetchhetri]

@nyh do you see any issues here at first glance?

[sumeetchhetri]

@nyh, @amnonh this is the integration piece that I was talking about, and the referenced sstring usage is here. Do let me know if anything is missing in this PR?

[nyh]

I don't understand the purpose of this patch. Besides seastar::sstring (and the almost identical std::string - see #634) which owns its content, we also have std::string_view which does not. Interfaces which should accept either should simply take std::string_view and require the caller to maintain this string's lifetime. Adding to seastar::string the possibility for both sounds dangerous to me - code which assumes it owns the content of an sstring may be surprised when it turns out that it doesn't.

In my experience, in the past we had less awareness of std::string_view so some Seastar or Seastar-application functions needlessly take const sstring& instead of std::string_view. We can and should change those functions, not sstring. We did this a lot in the Scylla application recently.

[nyh]

Regardless of whether this patch is needed at all (see my other comment) please note you shouldn't just add something to "external type" - it will make it longer, and longer than "internal_type", and waste space. What you can do is to replace the old "pad" with a single-byte flag. HOWEVER, this byte - in internal - is already used to for the internal size. So maybe you should pick a specific value (e.g., 255) which will say this is a ref. Should probably have a function (is_ref()) to abstract this check.

[nyh]

No, "u" is a union, you need to set either external or internal, you can't set both... In this constructor, the string is internal, so you musn't set external. The only byte common to both union members is the last one (size or pad). In fact, the sstring code would have been better and clearer if this byte was outside the union.