[CHANGED] Hide deleted objects by default

[piotrpio]

Addresses nats-io/nats-architecture-and-design#155

This PR introduces breaking changes to object store method signatures, as object store is still in experimental preview state.

[coveralls]

Coverage decreased (-0.03%) to 85.791% when pulling 08dd7d3 on hide-deleted-objects into 8e72eaa on main.

[kozlovic]

Although we can break since it was indeed marked experimental, do we have to? Is the idea here to logically separate get options vs put or some others? You could still have the internal objOpts have sub-structs for individual type of options: put, get, getinfo, etc... but still have options that are ObjectOpt, and "get" would just use the "get" options, etc...
But I agree that it would not prevent an user to pass say a "put" option to a "get" API, so in that sense it is better to have specific options, even if under the cover they could feed into a single internal option struct.

[piotrpio]

Yes, that is the idea. It is not a great user experience to be able to pass options to methods which make no sense. I think having it as separate type per method or group of similar methods makes things easier to the user (no guessing about which options apply to which methods).

Functional options are tricky either way, as you usually don't have the IDE support to e.g. easily find all options applying to a method, plus there is a possibility of options collisions, so I try to make it less complicated when possible.

[derekcollison]

If the options signatures are the same, meaning working code will still work and we only disallow what we thought was incorrect behavior I am ok with it.

[piotrpio]

TL;DR In GetInfo() and List() IgnoreDeletes() will not compile, but that's intentional as we want to hide deletes by default: nats-io/nats-architecture-and-design#155

@derekcollison so for each method for which ...ObjectOpt changed to ...GetObjectOpt it will work just fine, as there used to be only one option (nats.Context()) anyway, and that will work the same.

With GetInfo() and List() it is a bit different and it might require code changes as the option type changes from WatchOpt to GetObjectInfoOpt and ListObjectsOpt respectively.
So, in those 2 methods you won't be able to useoptions which did not make sense anyway (IncludeHistory() and MetaOnly() - they are not used anywhere in object store). Also you will not be able to use IgnoreDeletes(), but that is the point of this PR - to change the behavior and by default not show deleted objects, only enable them with option (GetObjectInfoShowDeleted())

[derekcollison]

We could allow IgnoreDeletes() to still compile right? That is easy to do.

[piotrpio]

Not really easy to do as IgnoreDeletes() returns a WatchOpt and I've changed the option types to be more tightly coupled to the methods they are used with.
We could get rid of the new types and just add ShowDeletes() as WatchOpt, but that is what I'm trying hard not to do - not to add options which only make sense in specific methods.

I know that it is a breaking change but fixing it in user's code is extremely simple (just remove IgnoreDeletes() from the call) so for experimental preview it should be all right.

[derekcollison]

LGTM