Add Lemmy 1.0.0 support

[MV-GH]

Seems to work in initial basic tests.

its deployed https://central.sonatype.com/artifact/it.vercruysse.lemmyapi/lemmy-api-jvm

Also fixes: #67

[MV-GH]

I released 0.6.0-beta.3, it doesn't contain any v1 changes but I have refactored the public API, see the README how it looks now. It also includes the Result<> changes. No more unexpected errors.

You can leave it for me, if you cant figure it out. You can stay on that version for now.

[MV-GH]

One of the changes was that cancellations no longer are catched for Result. As that's what recommended.

But I see now that timeouts are also cancellations

 REQUEST https://lemmy.world/api/v3/search?q=testAccount&type_=All&sort=TopAll&listing_type=All&page=1 failed with exception: java.util.concurrent.CancellationException: Request timeout has expired [url=https://lemmy.world/api/v3/search?q=testAccount&type_=All&sort=TopAll&listing_type=All&page=1, request_timeout=20000 ms]

Now these we do want to catch so that we can properly handle them. Show and then give those retry stuff. instead of silently failing.

I'll have to look further into this.

[MV-GH]

Okay nvm, the HttpRequestTimeoutException extends IOException not cancel. But Internally its wrapped in cancel exception which then gets logged but the actual exception that bubbles up is the HttpRequestTimeoutException. So it shouldn't be a problem. All thought should be confirmed in Jerboa itself, but tests here look good.

[dessalines]

Thx. I'll pull in that new version soon and let you know if I have any issues with it. Seems like the main thing (outside of instantiation) is that I should use getOrThrow() .

[MV-GH]

We only use one of those which should already be wrapped in try catch so you can indeed just do getOrThrow for that.

The bigger changes are that you need to create an okhttpclient and pass that to the LemmyApiClient and remove all those custom options we had and pass them using LemmyApiOptions. Because they were being layered on top each other instead of updating it. Even though we specified 30s timeout the 20s default was still active and winning since it was shorter. (I think 20s is more than enough tho).