Testing making TableData fault tolerant

If the data for a single run could not be found, it should not prevent
the data for other runs being returned.

The way async-graphql handles this is... odd. By making the resolver
return an Option<Result<T,E>> but only ever actually returning a Some(_)
variant, errors are added to the errors list in the response and the
rest of the query is executed as expected.

Adding the extra Option layer breaks error handling via the ? operator
which would make the resolver noisy so the inner logic is moved into a
non-object impl block which can then be called and wrapped by the
graphql macro wrapped version of the same method.

Author: tpoliaw

src/model.rs

@@ -135,6 +135,16 @@ impl TableData {
         &self,
         ctx: &Context<'_>,
         columns: Option<Vec<String>>,
+    ) -> Option<Result<HashMap<String, Vec<Value>>>> {
+        Some(self.inner_data(ctx, columns).await)
+    }
+}
+
+impl TableData {
+    async fn inner_data(
+        &self,
+        ctx: &Context<'_>,
+        columns: Option<Vec<String>>,
     ) -> Result<HashMap<String, Vec<Value>>> {
         let auth = ctx.data::<Option<AuthHeader>>()?;
         let headers = auth.as_ref().map(AuthHeader::as_header_map);