added seek interface

[lihui815]

Per #824, created seek(timestamp) method in rosbag2_storage::storage_interfaces::ReadOnlyInterface API.

• added seek(timestamp)
• default sqlite implementation:
  • seek implementation keeps the storage filter, but will re-run the query with a new seek_time
  • updated set_filter/reset_filter to be able to be called in between reads in place. This means that if the message topics were in the order of:

    1 AAA
    2 BBB
    3 CCC
    4 AAA
    5 BBB
    6 AAA
    

    and we set filter on topic AAA after reading two messages (AAA & BBB), the next message read would be the AAA on the 4th row.
• added seek implementation to sequential reader (assumes multi-file is in time order)
  • needs to reset the current file to the first file in order to be able to skip backwards
  • read_next() calls has_next() to ensure that reader rolls over to next file at end of current file
  • has_next() calls itself recursively until either there is a next row or there are no more files (doesn't assume that the next file will definitely contain valid row)
• added tests for seeking/filtering both single and multi-file bags

NOTE

Because of continued confusion in the comments, I'm highlighting here the difference between

• sqlite implementation of storage_interfaces::ReadOnlyInterface->seek(t)
• SequentialReader->seek(t)

The differences are as follows:

• reading in time order:
  • SqliteStorage DOES guarantee time-ordered reads regardless of write order. This means that calling seek(t) will also guarantee subsequent read_next() calls to return messages in time order until the end of the file.
  • SequentialReader DOES NOT guarantee time-ordered reads if individual files within a bag are not in non-overlapping sequential time order ("Time normalize" bag written from API so that splits are in order #842). This means that, with or without calling seek(t), there may be messages that occur at an earlier timestamp than previously-read messages when one file rolls over to the next file. SequentialReader->seek(t) will only guarantee that all messages and only messages with timestamp >= t will be read (satisfying any topic filters).
• In-place setting/resetting of topic filters:
  • in SqliteStorage, messages are queried in time order. The implicit tiebreaker between messages of the same timestamp is on the row id. This PR makes this second-degree ordering explicit. When we modify topic filters "in place", we actually rerun the query of the db file. In order to prevent re-reading previously read messages, we filter the timestamp to prevent reading "older" messages, AND we filter row-id to prevent reading already-read messages at the current timestamp. Note that if we don't assume write order (consistent with existing SqliteStorage implementation), we need to do both. For example:

     # write order
      row0 t1 msgA
      row1 t0 msgB
      row2 t0 msgC
      row3 t2 msgD
      row4 t1 msgE
    
      # read order
      row1 t0 msgB
      row2 t0 msgC  <-- same timestamp as msgB but loses row_id tiebreak
      row0 t1 msgA  <-- later timestamp than msgB & msgC, but lower row-id
      row4 t1 msgE  <-- same timestamp as msgA but loses row_id tiebreak
      row3 t2 msgD
    

    From this example, if we set topic filter between reading msgA and msgE, then we need to check against the last read message time t1 to prevent previously read messages msgB and msgC to be re-read, and to check against the row id row0 to make sure that msgA doesn't get re-read. This is why in the SqliteStorage implementation we update seek_time_ and seek_row_id_ with every read, to make sure that we can make the correct in-place update query. Thus the filter query is necessarily (timestamp > last_t) or (timestamp = last_t and row_id > last_rid).
  • in SequentialReader, this is not applicable. When setting/resetting topic filters the "in place pointer" is kept by reference to the current file. We can assume that all files previous to the current file have already been read, so the setting/resetting of topic filters just occurs on the current & subsequent files. Within the current file, the "in place" message pointer is already handled by the single-file storage implementation.

[emersonknapp]

LGTM

[emersonknapp]

• Linux
• Linux-aarch64
• macOS
• Windows

requests addressed

[MichaelOrlov]

I am requesting for changes in sqlite_storage.cpp to cleanup logic since in current stage it's misleading further in sequential_reader

see updated description for why query can't be simplified.

[emersonknapp]

• Linux
• Linux-aarch64
• macOS
• Windows