[IOTDB-172]fix a bug of TsFileResource updateTime

[LeiRui]

Bug Description:
When recovering a TsFile's device -> start time and device -> end time map and the TsFile's resource file happens not to exist, the TsFile itself will be read to update the start and end time map instead. It is implemented by TsFileRecoverPerformer.recover as follows:

for (TsDeviceMetadataIndex index : deviceMetadataIndexList) {
  TsDeviceMetadata deviceMetadata = reader.readTsDeviceMetaData(index);
  List<ChunkGroupMetaData> chunkGroupMetaDataList = deviceMetadata.getChunkGroupMetaDataList();
  for (ChunkGroupMetaData chunkGroupMetaData : chunkGroupMetaDataList) {
    for (ChunkMetaData chunkMetaData : chunkGroupMetaData.getChunkMetaDataList()) {
      tsFileResource.updateTime(chunkGroupMetaData.getDeviceID(), chunkMetaData.getStartTime());
      tsFileResource.updateTime(chunkGroupMetaData.getDeviceID(), chunkMetaData.getEndTime());
    }
  }
}

The updateTime function uses the first-coming value as the startTime:

  public void updateTime(String deviceId, long time) {
    startTimeMap.putIfAbsent(deviceId, time);
    Long endTime = endTimeMap.get(deviceId);
    if (endTime == null || endTime < time) {
      endTimeMap.put(deviceId, time);
    }
  }

So when root.vehicle.d0 has a chunkgroup of chunkMetadata listed as:
s3: startTime=3000, endTime=10000;
s1: startTime=1000, endTime=10000;
s2: startTime=2000, endTime=10000;
By the current code, the updated start time will be the first coming 3000, which is not correct.

---

By the way, I also change updateTime in LogReplayer.replayLogs to updateStartTime and updateEndTime. If there is something I haven't noticed, please tell me.

[MyXOF]

please add ut to cover this case

[LeiRui]

please add ut to cover this case

added ☺️

[jixuan1989]

Hi, is there an jira issue attached this PR?
We need to manage the solved version on that.

[jt2594838]

You may just remove this method.

[LeiRui]

removed

[LeiRui]

Hi, is there an jira issue attached this PR?
We need to manage the solved version on that.

Added. See IOTDB-172.