rpc: optimize small tuple deserialization

When rpc deserializes a tuple, it cannot do so into a std::tuple
constructor arguments, since argument evaluation order is unspecified
but deserialization must proceed left-to-right. So we deserialize after
the tuple is constructed.

However, if the tuple has zero or one elements, then there is no
reordering problem. Take advantage of that and deserialize in the
constructor, saving some steps.

I observed a significant reduction in text size in ScyllaDB's
messaging_service.o:

   text	   data	    bss	    dec	    hex	filename
6797398	     48	    236	6797682	 67b972	messaging_service.o.before
6758146	     48	    236	6758430	 67201e	messaging_service.o.after

A 40kB reduction.

include/seastar/rpc/rpc_impl.hh

@@ -327,12 +327,19 @@ inline std::tuple<T...> do_unmarshall(connection& c, Input& in) {
     // left-to-right. So we deserialize into something that can be lazily
     // constructed (and can conditionally destroy itself if we only constructed some
     // of the arguments).
+    //
+    // As a special case, if the tuple has 1 or fewer elements, there is no ordering
+    // problem, and we can deserialize directly into a std::tuple<T...>.
+  if constexpr (sizeof...(T) <= 1) {
+    return std::tuple(unmarshal_one<Serializer, Input>::template helper<T>::doit(c, in)...);
+  } else {
     std::tuple<std::optional<T>...> temporary;
     return std::apply([&] (auto&... args) {
         // Comma-expression preserves left-to-right order
         (..., (args = unmarshal_one<Serializer, Input>::template helper<typename std::remove_reference_t<decltype(args)>::value_type>::doit(c, in)));
         return std::tuple(std::move(*args)...);
     }, temporary);
+  }
 }
 
 template <typename Serializer, typename... T>