Split timestamp_end_opened_at_ into 2 separate timestamps

[jp-dark]

The private Array variable timestamp_end_opened_at_ is being used for two different use cases:

1. Specify end of timestamp range for fragments to load from file.
2. Specify timestamp to use for new fragments, metadata, etc.

Split the private variable into two variables to make this explicit.

---

TYPE: IMPROVEMENT
DESC: Internal clean-up of array timestamps

[davisp]

To start with, this change looks good to me. It definitely makes a lot of the logic more obvious than it was previously.

I'm only marking this review as a comment as it's mostly a "I wonder if..." sort of review. Feel free to ignore it if you don't think its worth pursuing.

So, I wonder if this could be further improved by creating an ArrayDirectoryTimeRange class (or something with a better name). I'm basically thinking something like:

class ArrayDirectoryTimeRange {
  public:
    ArrayDirectoryTimeRange(optional<uint64_t> start, optional<uint64_t> end)
        : start_(start)
        , end_(end) {}

    std::pair<uint64_t, uint64_t> time_range_for_reads();
    uint64_t time_for_writes();
    
    /* whatever other helper APIs */

  private:
    optional<uint64_t> start_;
    optional<uint64_t> end_;
}

I haven't thought through all the APIs that might be needed, but from what I see there is one fundamental thing happening (The user provided start and/or end timestamps) and then we adjust how we use those based on the situation (i.e., reads vs writes vs reopen vs other things).

Also, if you're not immediately convinced, I'm already on the hook for improving the UPDATE and DELETE handling in ArrayDirectory next sprint so can probably dedicate a couple hours to giving this a whirl. It seems like one of those things where it'll be pretty clear right away whether its going to be better or worse.

[davisp]

Also, an official +1 in case that wasn't obvious.

[jp-dark]

So, I wonder if this could be further improved by creating an ArrayDirectoryTimeRange class

I think that would be a reasonable follow-up task. This PR was always intended to be a first step in improving our handling of timestamps.

[davisp]

More than reasonable!

[KiterLuc]

Filed https://app.shortcut.com/tiledb-inc/story/36504/refactor-array-directory-start-end-timestamps for follow up.