The prev solution was to clean up the tracker points before the new track recording starting.
It was not fully correct solution because:
1. it causes the bug, when if we starts a recording, the `TrackRecordingUpdateHandler` is called by subscribers but receives the old `track info` from the previous track. It happens because the starting is an async call and it cleans up the gps collection a little bit later.
2. when the user finishes the track recording the collection is not properly cleared. The data will stay in the memory `forewer` until the next recording is started. And this data will be recovered on the next app launch too. There are no reason to store all the recorded data in memory until the new recording begins. This approach was Ok for the `previous path` feature (removed) but not for the TR. The data lifecycle for the both feature should be handled separately.
Signed-off-by: Kiryl Kaveryn <kirylkaveryn@gmail.com>
To retrieve as a `GpsTrackInfo` struct that will be used to notify the UI about the track recording process.
Signed-off-by: Kiryl Kaveryn <kirylkaveryn@gmail.com>
Because of the `RecentPath` feature was replaced with the `TrackRecording`
the the file's tail shouldn't be truncated by the system. User can record
track for more than 24h. This is why the `Duration`, `TruncFile` and `m_maxItemCount`-rleated code
was removed.
Signed-off-by: Kiryl Kaveryn <kirylkaveryn@gmail.com>
