Add client method to wait for attachment processing

[dscottboggs]

This should resolve #61. @SpriteOvO, can you confirm this suits your use-case?

[SpriteOvO]

@dscottboggs I'll check it tonight. Thanks.

[SpriteOvO]

wait_for_processing method may loop forever if the server always does not process the attachment?

I think the new method wait_for_processing should consider the timeout case inside. How about this signature?

pub async fn wait_for_processing(
        &self,
        mut attachment: Attachment,
        polling_interval: Duration,
        timeout: Duration,
    ) -> Result<ProcessedAttachment>

[dscottboggs]

done

[SpriteOvO]

LGTM. Thank you! :)

Although a more appropriate way to implement the timeout is to use the tokio::select!, so that it will return immediately if it times out, instead of remaining asleep. But in this case, the value of polling_time user input is most likely very short, so this is not a big problem.

[dscottboggs]

Well, now that you say that, I don't think I'm going to keep this feature.

1. I feel that this is actually more clear about what's happening:

   let processed_attachment = tokio::time::timeout(
       Duration::from_secs(90),
       mastodon.wait_for_processing(attachment, Default::default())
   ).await??;

2. The API will return an error in the case processing has failed, in which case the wait_for_processing method will return

   Err(mastodon_async::Error::Api {
       status: reqwest::StatusCode::UNPROCESSABLE_ENTITY,
       error: ApiError { error: "Validation failed: File content type is invalid, File is invalid", error_description: None }
   })

   This means that any situation which would cause an infinite loop here would be a bug in the server. We can't go around trying to anticipate and account for every potential bug that could surface in the future. If such a bug were to surface, and a fix was not accepted upstream, it would be worth considering, but for now I think it's safe to rely on the server to provide us with sensible errors. Plus, if anyone wants to add a timeout downstream, see the first point.
3. I don't like the extra parameterization. I don't even like having the polling time as a parameter, it's completely unclear at the call site what the duration being passed there is for, unless someone specifically uses the PollingTime type just to make it clear. It's less than ergonomic, but sometimes that's just what works, so it's fine.