add for_buf function

[secana]

Add a function that takes a buffer that is already in memory and scan it with vaas instead of a file path or stream.

[GermanCoding]

I agree our current function signature for streams isn't great and should be improved. That said, it is possible to use bufs + for_stream with about 5 lines of code like this:

https://github.com/GDATASoftwareAG/vaas/commit/8339801df46fad8fe00d68f1d8fc3f7384fdf476

    pub async fn for_buf(&self, buf: Vec<u8>, ct: &CancellationToken) -> VResult<VaasVerdict> {
        let len = buf.len();
        let stream = stream::once(async move {
            Ok::<Vec<u8>, std::io::Error>(buf)
        });
        self.for_stream(stream, len, ct).await
    }

[secana]

I agree our current function signature for streams isn't great and should be improved. That said, it is possible to use bufs + for_stream with about 5 lines of code like this:

8339801

    pub async fn for_buf(&self, buf: Vec<u8>, ct: &CancellationToken) -> VResult<VaasVerdict> {
        let len = buf.len();
        let stream = stream::once(async move {
            Ok::<Vec<u8>, std::io::Error>(buf)
        });
        self.for_stream(stream, len, ct).await
    }

I like that, I'll change the code to use stream internally. What we have to decide is, if we want to break the API and use Stream in the for_stream function. Currently we use TryStream which make the API complicated, as everything has to be wrapped into a fail-able async type. We did that back then, 'cause that's the type that reqwest returns, which makes it plug'n'play with taking a reqwest response and putting it into a stream request. But I'm not sure if that is what the for_stream API should do. What do you think about that?

Maybe we just add the for_buf method (wich uses for_stream internally) for a 6.1.0 version and think about a cleaner for_stream for a 7.x.x. function, 'cause it's a breaking change, if we change the API.

[secana]

Okey, the for_stream does not check the SHA256, so it's not an option to use it in that case.

[GermanCoding]

I had yet another refactoring idea in #618: Generalize the uploading altogether, adding a new trait that specifies upload-data types. With this trait, adding support for things like for_buf (& many other types) is trivial with minimal code changes. The design still isn't perfect, but do you have an opinion on this?