Add new functions that use HttpRequest and Try to eventually replace Fuel and Promises

[stevenzeck]

This PR creates new functions that use the DefaultHttpClient and Try to eventually replace the existing ones that use Fuel and Promises.

• The two parseUrlString functions are the replacements for the parseURL ones (applicable to OPDS1Parser and OPDS2Parser)
• Instead of accepting a URL, it accepts a String and an optional HttpClient (both)
• retrieveOpenSearchTemplate is the replacement for fetchOpenSearchTemplate (OPDS1Parser)
• For Instead of returning a Promise, it returns a Try (both)
• parseURL and fetchOpenSearchTemplate are both marked as deprecated with a warning (both)
• New function, parseRequest, that accepts an HttpRequest and an optional HttpClient
• Deprecated functions use the DefaultHttpClient, replacing Fuel, thus removing Fuel as a dependency

I took the liberty of naming the new functions, but feel free to change them.

[mickael-menu]

Thanks for taking a stab at this! 🚀

[mickael-menu]

It could be interesting to take a client argument to let the app provide its own implementation if necessary.

Also an additional parseRequest() API taking directly an HttpRequest would let the app customize the HTTP headers, timeouts and other settings without a custom HttpClient. This way we don't need to provide parseUrlString(url: String, headers: MutableMap<String, String>).

Suggested change

	suspend fun parseUrlString(url: String): Try<ParseData, Exception> {
	suspend fun parseUrlString(url: String, client: HttpClient = DefaultHttpClient()): Try<ParseData, Exception> {
	...
	}
	suspend fun parseRequest(request: HttpRequest, client: HttpClient = DefaultHttpClient()) ...

[stevenzeck]

I think we can actually just have one function in that case: Accepts a URL as a string, and accepts an HttpClient with the default being DefaultHttpClient. And parseRequest sounds better than parseUrlString.

[qnga]

I wonder why you want to make HTTP requests inside a parser... Am I missing something?
Also, if the API is going to be freshened up, it might be the right time to enforce the new naming conventions: Opds2Parser, Opds1Parser.

[mickael-menu]

I wonder why you want to make HTTP requests inside a parser... Am I missing something?

That's a good point. Down the line, I'd like to offer a more high-level API which would handle:

• A version-agnostic parser (OPDS 1 or OPDS 2)
• Transparent implementation of Authentication for OPDS
• (Maybe) Something to alleviate the issues mentioned here OPDS: How to handle outdated feeds in the user interface? mobile#20

Some of these will need control over the HTTP requests.

But for this PR, I think the goal is mostly to keep feature parity with the existing implementation while deprecating Fuel and kovenant.

[stevenzeck]

Yeah, this PR was about replacing Kovenant and Fuel. I just realized that the old functions that still use Fuel can actually use the new Http service, as long as they still use Kovenant to return a Promise. That will at least remove the need for Fuel though.

[stevenzeck]

@mickael-menu made the suggested changes.

[mickael-menu]

Thanks @stevenzeck!