[Auth restructure 1] Separate http into a new crate

[marioortizmanero]

Part 1 of splitting up #207.

This moves the http logic into its own crate. It should be able to compile by itself (but not rspotify itself)

[ramsayleung]

This moves the http logic into its own crate. It should be able to compile by itself (but not rspotify itself)

As for this point, http crate should be able to compile by itself, isn't possible to separate the GitHub Action CI flow by crate instead of put them all into one CI flow? Then in this PR, the http crate should pass the CI check

[marioortizmanero]

It's a bit complicated/cumbersome to do so... For now I guess you can just run the tests locally for the http crate?

Can we first talk about how cross-compilation isn't really necessary for the CI? I don't see what could possibly cause a fail in one architecture that doesn't happen in another; we don't have architecture-specific code. If we simplify that then we might be able to have a flow per crate as you suggest, but otherwise with 4 crates, 3 architectures and 2 possible configurations (ureq and reqwest) we would have a total of 4 * 3 * 2 = 24 CI flows just for the tests... Which would grow even bigger if we added more HTTP clients.

[ramsayleung]

Can we first talk about how cross-compilation isn't really necessary for the CI?

Yeah, cross-compilation isn't high priority, so it's ok to move these cross-compilation CI flow, and doesn't need to compile for different architectures.

[ramsayleung]

Beside the nitpick I mentioned, everything looks good to me.

Finally, the reviews of all PR are done :)

[ramsayleung]

Is it a better choice to have new names instead Error and Result, since it's conflicting with the type defined in standard library, might cause a bit of confusion.

[marioortizmanero]

Most libraries also use Error, you can then use it as http::Error to avoid ambiguity wherever needed. The thing is that we'd have to change ClientError to be rspotify::Error as well for consistency. But seeing that we have ApiError as well it might be more clear by using a prefix. I'll change it to HttpError, but if you think the other option is better let me know and I'll undo it.

[ramsayleung]

HttpError is good enough :)