Remove ids from the exporter implementation further shifting the burden

of managing exporter identities to the control/client so it can be
unified and kept an implementation detail as much as possible.
Implement support for multiple exporter responses in APIs.

api/services/control/control.proto

@@ -35,7 +35,7 @@ message PruneRequest {
 }
 
 message DiskUsageRequest {
-	repeated string filter = 1; 
+	repeated string filter = 1;
 }
 
 message DiskUsageResponse {
@@ -105,7 +105,12 @@ message CacheOptionsEntry {
 }
 
 message SolveResponse {
-	map<string, string> ExporterResponse = 1;
+        // ExporterResponseDeprecated is a combined exporter response - it aggregates
+        // responses from all exporters running in parallel.
+        // It is deprecated in favor of the structured exporter response but will be
+        // populated as long as it is supported.
+	map<string, string> ExporterResponseDeprecated = 1;
+	repeated ExporterResponse exporterResponses = 2;
 }
 
 message StatusRequest {
@@ -249,3 +254,17 @@ message Exporter {
 	// ID should be treated by the exporter as opaque.
 	string ID = 3;
 }
+
+// ExporterResponse describes the output of an exporter
+message ExporterResponse {
+    // Metadata describes the exporter
+    ExporterMetadata metadata = 1;
+    // Data is the exporter's output
+    map<string, string> data = 2;
+}
+
+// ExporterMetadata describes the output exporter
+message ExporterMetadata {
+    // ID identifies the exporter
+    string ID = 1;
+}