Parse GitlabFeatures from the JobResponse

This is the other half of the capability signalling that Gitlab does.
Not only does a runner signal what features it is capable of supporting
when making a request, but the server also provides some information
back to the runner about what capabilities it provides.

There are currently three capabilities Gitlab can indicate it has
(this commit only adds parsing not support):

- Separating the trace into sections for easier viewing.
- Prefix masking (it's not totally clear why this is a Gitlab feature -
  but this is the mechanism by which the prefix masks are communicated to
  a runner willing to mask them).
- Failure reasons.

The end goal here is support for prefix masking, so that things like
PAT tokens are all automatically masked system-wide in logs.

Author: eds-collabora

gitlab-runner/src/client.rs

@@ -168,6 +168,16 @@ pub(crate) struct JobDependency {
     pub artifacts_file: Option<JobArtifactFile>,
 }
 
+#[derive(Debug, Clone, Deserialize, PartialEq, Eq)]
+pub(crate) struct GitlabFeatures {
+    #[serde(default)]
+    pub trace_sections: bool,
+    #[serde(default, deserialize_with = "deserialize_null_default")]
+    pub token_mask_prefixes: Vec<String>,
+    #[serde(default, deserialize_with = "deserialize_null_default")]
+    pub failure_reasons: Vec<String>,
+}
+
 #[derive(Debug, Clone, Deserialize, PartialEq, Eq)]
 pub(crate) struct JobResponse {
     pub id: u64,
@@ -180,6 +190,8 @@ pub(crate) struct JobResponse {
     pub dependencies: Vec<JobDependency>,
     #[serde(deserialize_with = "deserialize_null_default")]
     pub artifacts: Vec<JobArtifact>,
+    #[serde(default)]
+    pub features: Option<GitlabFeatures>,
     #[serde(flatten)]
     unparsed: JsonValue,
 }