refactor: introduce ObjectStoreExt trait

[crepererum]

Which issue does this PR close?

• First part of Cleanup ObjectStore trait: Split out convenience methods #385.

Rationale for this change

See #385.

What changes are included in this PR?

• the trait
• put method migrated

Are there any user-facing changes?

1. users may need to import another trait
2. users no longer can / have to implement put

[crepererum]

Technically the extension crate doesn't need async_trait because it is never dyn-dispatched (it may use a dyn-dispatched ObjectStore though). However our MSRV doesn't support that yet. So there are two options:

• bump MSRV to 1.75
• use async_trait for the extension crate as well, resulting in another indirect call. This is likely never going to be noticeable though, since it's not a hot path. Another downside of it is that the docs generated by async_trait aren't so great (cargo doc generates ugly documentation dtolnay/async-trait#213).

[alamb]

Changes
users may need to import another trait
users no longer can / have to implement put

I think this makes sense, but will potentially be disruptive to downstream crates (will have to figure out they need now to use ObjectStoreExt).

I think the Rust compiler error messages will do a reasonable job of telling them what is going on, but adding some additional documentation could help make the transition easier.

use async_trait for the extension crate as well, resulting in another indirect call. This is likely never going to be noticeable though, since it's not a hot path

I think this is more consistent with the rest of the crate and would be preferred suggestion

bump MSRV to 1.75

It seems like 1.75 was released 1.5 years ago, which is a long time in Rust terms but maybe we can avoid making the next upgrade too painful

cc @tustvold

[crepererum]

I plan to migrate other methods in follow-up PRs. I just wanted to keep this PR rather simple.

[tustvold]

Taken a quick look, unfortunately very short on time this week.

I think the major question from me is if this is premature, in particular we don't currently have a list_opts or copy_opts method, and in the former case it isn't immediately obvious what this would look like. Similarly methods like get_ranges have specializations that make a material difference.

The reason I've held off doing something like this before is that some methods are not obvious how they'd fit into this, I'd feel more comfortable to have a plan for these before committing to this approach

[crepererum]

Taken a quick look, unfortunately very short on time this week.

I think the major question from me is if this is premature, in particular we don't currently have a list_opts or copy_opts method, and in the former case it isn't immediately obvious what this would look like. Similarly methods like get_ranges have specializations that make a material difference.

The reason I've held off doing something like this before is that some methods are not obvious how they'd fit into this, I'd feel more comfortable to have a plan for these before committing to this approach

I think we'll likely cover the following methods via _opts:

• get (except "rangeS")
• put
• put multipart
• copy
• rename

IMHO that are enough methods.

[crepererum]

@tustvold do you wanna put a veto in against this change? Otherwise @alamb and myself are going to push for this and follow-up clean-up for other methods for the upcoming 0.13 release. I also found a good prior art now which is rand::Rng VS rand::RngCore.

[tustvold]

No objections from me, sorry didn't realise this was waiting on me

[alamb]

i think it is a good change

@kylebarron / @mbrobbel do you have any additional thoughts / suggestions about this idea (mainly make the ObjectStore trait itself simpler so it is clearer what is required to be implemented and what isn't)

I like the change as it more clearly distinguishes the API that is useful for users of the ObjectStore trait and implementers of ObjectStore

If we go with this approach I think we should migrate all similar methods before the next breaking release to miniimize downstream churn

[mbrobbel]

+1 for splitting the trait

[kylebarron]

I haven't followed discussion; is put the only method intended to put on this ext trait? for example get_ranges has a default implementation but isn't in this ObjectStoreExt trait

[crepererum]

there gonna be more methods that move (e.g. get), but I wanted to keep this PR kinda manageable.

[kylebarron]

oh I see. How does it work to override methods in ObjectStoreExt? For example get_ranges currently hardcodes the coalesce size and in obstore I want to make that configurable. I guess it would be simplest to use my own helper function that calls get_range?

[crepererum]

I'm not sure how far I get with the get_range(s) family in this release but my long term plan is to fold them into get_opts as well. I think we need to somewhat rework the return type of get & Co to be more flexible, but that needs a bit more brain work.

[kylebarron]

• bump MSRV to 1.75

#515 bumped msrv. Does that change this pr at all?

[crepererum]

• bump MSRV to 1.75

#515 bumped msrv. Does that change this pr at all?

no longer, will update