object_store: Migrate from snafu to thiserror

[Turbo87]

Which issue does this PR close?

#6166, though only partially, since the PR is only targeting the object_store crate.

Rationale for this change

The rationale is explained in the linked issue :)

What changes are included in this PR?

The first commit in the PR adds a dependency on thiserror, the following commits incrementally port all error enums from snafu to thiserror, and then the final commit removes the now obsolete snafu dependency.

Note that this PR also includes #6265 to avoid merge conflicts from the bugfix.

Are there any user-facing changes?

As the linked issue mentions, some of the snafu type may leak to the outside and this PR will remove them so this should probably be treated as a breaking change, even though these types have been considered private API before.

[Turbo87]

/cc @tustvold :)

[tustvold]

HI @Turbo87, thank you for this, it looks pretty spot on. Unfortunately this ended up missing the 0.11 release, the RC was cut on the 12th August, and the next breaking release will not be for another 3 months...

I'm not really sure what the best way to proceed with this is, as we can't merge it to master for another 2 months. One option might be to keep this PR as a draft until then, but I appreciate that's likely a longer time commitment than you might have reasonably intuited when you picked this up 😅

Also tagging @Xuanwo and @alamb who may have other thoughts

[Turbo87]

the next breaking release will not be for another 3 months

no worries :)

as we can't merge it to master for another 2 months

any reason for not being able to merge before then? I would guess potential bug fixes could be branched off before the merge of this PR, but I'm not familiar with the release process here :D

[tustvold]

any reason for not being able to merge before then

Non-backport releases, including minor releases, are made from master. There have been some discussions in the past about alternative approaches, but they're not without their own trade-offs. #5907

[alamb]

I am depressed about the large review backlog in this crate. We are looking for more help from the community reviewing PRs -- see #6418 for more

[findepi]

I am depressed about the large review backlog in this crate. We are looking for more help from the community reviewing PRs -- see #6418 for more

Smaller PRs are faster to merge, because the review time is more than linear.

@Turbo87 your PR has awesome commit-by-commit structure. Would you consider moving eg first ~4 commits to a separate one?

[tustvold]

This PR is probably fine as is, it's largely mechanical, it is actually just waiting on us to start preparation for the next breaking release

[Turbo87]

Would you consider moving eg first ~4 commits to a separate one?

we can do that, but I'm not sure how valuable that would actually be since we'd then end up in a situation where we have both dependencies in the Cargo.toml file. it's probably easiest to review this commit-by-commit. since the changes are indeed pretty mechanical this should get quicker after reviewing the first few commits.

[Turbo87]

FYI I've just rebased the branch to fix the merge conflict and integrate #6266 (comment)

[Turbo87]

rebased again to fix merge conflicts caused by #6453

[jondot]

This is great! I've been looking for this to optimize builds of Loco (https://github.com/loco-rs/loco)

[Turbo87]

rebased once more and updated to thiserror v2