Introduce separate Serve protocol serialisers

To start, it is just a clone of the common protocol. But now that we
have the separate protocol implementations, we can add versioning
information without the versions of one protocol leaking into another.

Using the infrastructure from the previous commit, we don't have to
duplicate code for shared behavior.

Motivation: No more perverse incentives. [0] did some awkward things
because the serialisers did not store the version. I don't want anyone
making changes to be pushed towards keeping the serialization logic with
the core data types just because it's easier or the alternative is
tedious.

The actual versioning of the Worker and Serve protocol serialisers
(Common remains unversioned as the underlying mini-protocols are not
versioned) will happen in subsequent commits / PRs.

[0]: fe1f34fa60

src/libstore/serve-protocol.hh

@@ -1,6 +1,8 @@
 #pragma once
 ///@file
 
+#include "common-protocol.hh"
+
 namespace nix {
 
 #define SERVE_MAGIC_1 0x390c9deb
@@ -10,6 +12,11 @@ namespace nix {
 #define GET_PROTOCOL_MAJOR(x) ((x) & 0xff00)
 #define GET_PROTOCOL_MINOR(x) ((x) & 0x00ff)
 
+
+class Store;
+struct Source;
+
+
 /**
  * The "serve protocol", used by ssh:// stores.
  *
@@ -22,6 +29,57 @@ struct ServeProto
      * Enumeration of all the request types for the protocol.
      */
     enum struct Command : uint64_t;
+
+    /**
+     * A unidirectional read connection, to be used by the read half of the
+     * canonical serializers below.
+     *
+     * This currently is just a `Source &`, but more fields will be added
+     * later.
+     */
+    struct ReadConn {
+        Source & from;
+    };
+
+    /**
+     * A unidirectional write connection, to be used by the write half of the
+     * canonical serializers below.
+     *
+     * This currently is just a `Sink &`, but more fields will be added
+     * later.
+     */
+    struct WriteConn {
+        Sink & to;
+    };
+
+    /**
+     * Data type for canonical pairs of serialisers for the serve protocol.
+     *
+     * See https://en.cppreference.com/w/cpp/language/adl for the broader
+     * concept of what is going on here.
+     */
+    template<typename T>
+    struct Serialise;
+    // This is the definition of `Serialise` we *want* to put here, but
+    // do not do so.
+    //
+    // See `worker-protocol.hh` for a longer explanation.
+#if 0
+    {
+        static T read(const Store & store, ReadConn conn);
+        static void write(const Store & store, WriteConn conn, const T & t);
+    };
+#endif
+
+    /**
+     * Wrapper function around `ServeProto::Serialise<T>::write` that allows us to
+     * infer the type instead of having to write it down explicitly.
+     */
+    template<typename T>
+    static void write(const Store & store, WriteConn conn, const T & t)
+    {
+        ServeProto::Serialise<T>::write(store, conn, t);
+    }
 };
 
 enum struct ServeProto::Command : uint64_t
@@ -58,4 +116,33 @@ inline std::ostream & operator << (std::ostream & s, ServeProto::Command op)
     return s << (uint64_t) op;
 }
 
+/**
+ * Declare a canonical serialiser pair for the worker protocol.
+ *
+ * We specialise the struct merely to indicate that we are implementing
+ * the function for the given type.
+ *
+ * Some sort of `template<...>` must be used with the caller for this to
+ * be legal specialization syntax. See below for what that looks like in
+ * practice.
+ */
+#define DECLARE_SERVE_SERIALISER(T) \
+    struct ServeProto::Serialise< T > \
+    { \
+        static T read(const Store & store, ServeProto::ReadConn conn); \
+        static void write(const Store & store, ServeProto::WriteConn conn, const T & t); \
+    };
+
+template<typename T>
+DECLARE_SERVE_SERIALISER(std::vector<T>);
+template<typename T>
+DECLARE_SERVE_SERIALISER(std::set<T>);
+template<typename... Ts>
+DECLARE_SERVE_SERIALISER(std::tuple<Ts...>);
+
+#define COMMA_ ,
+template<typename K, typename V>
+DECLARE_SERVE_SERIALISER(std::map<K COMMA_ V>);
+#undef COMMA_
+
 }