Unify request/response types at the FacTec API client

[tonycdot]

Resolves #70.
To do:

• remove CommonResponse
• remove AlreadyEnrolled
• remove custom error structs and change common one
• remove error field in all Response structs
• resolve the TODOs at the documentation of the FaceScanSecurityChecks fields
• implement Deserialize for FacetecResponse
• clean up robonode-server
• test error response without error_message and non-error with it

[MOZGIII]

Removing CommonResponse is reasonable since we don't really use it in our business logic. AlreadyEnrolled too - it was just an unused value.

Is there more work planned here? If so, I suggest creating a TODO list in the PR (i.e. like at #38 and #31).

I recall we discussed things like having a single common type for the errors, and extracting error and success into a common response. Is there a change of plans regarding those?

While reviewing the code, I've noticed some other potential improvements:

1. We can move FaceScanSecurityChecks and FaceScanResponse types to enrollment3d.rs, since they're not used elsewhere.
2. It would be nice if we could resolve the TODOs at the documentation of the FaceScanSecurityChecks fields.

[tonycdot]

It would be nice to have smth like this:

#[derive(Debug, Deserialize)]
#[serde(tag = "error")]
enum FacetecResponse<T> {
    /// Error response variant.
    #[serde(rename = true)]
    Err(ServerError),
    #[serde(rename = false)]
    /// Correct response variant.
    Ok(T),
}

But this serde issue is open since 2017, and this pull request is closed, so I decide to reconsider it a bit.
Field error equals to true seems to be always accompanied by error_message, so we can ignore it entirely.

[MOZGIII]

Field error equals to true seems to be always accompanied by error_message, so we can ignore it entirely.

This is what we observed so far, but I don't think we can prove it's actually the case.

My thinking is this: if our intention is to decide whether it's an error or not is based on the error value - then it is what we have to code. If we encounter a case where error is true and there's no error message - well, that would be a parsing error, and we'll easily spot it. If we do this the other way - that is using the presence of an error message itself as an indicator - we'll be unable to detect the case where the error is true and an error message is absent because the behavior that we'll get instead is failed parsing attempt on T; while it should've been parsed as an error.

My suggestion here would be using the error-value-based parsing, and adding explicit test cases for:

• empty json - which should result in a json parsing error
• json with error true and no errorMessage - which should also result in a json parsing error
• json with error false but with an errorMessage - which should parse as T

We might want to add some subclassification for ResponseBody::Json error - to indicate whether an error was at parsing the helper with an error field, the ServerError or T. If we do, we need to make sure it's properly set in tests.