Limit requests to Peaks inside SummitedPeaks, parallelize strava fetch

[Yeetii]

There are too many requests being made to Peaks in SummitedPeaks which is limiting performance and hitting the RU limit. When performing batch processing of SummitedPeaks multiple activities must share the same request to Peaks.

Group together activities before doing fetch?

• Grouping based on pagination in strava
  • [x] Make each paginated fetch of activites a Task
  • [x] Once each activity fetch finishes spin up the mapping
• [ ] Function that calculates a collective center point and radius that would cover a list of activites, could be pretty rough
  • Random activities starting point, radius = largest distance to starting point + max distance
  • Split group into two if radius grows too large? <- Seems kinda complicated and would probably not be necessary for most cases. Although activities on different continents would really fuck this up.

Generalize request so they can be saved and reused?

• Would removing some decimal points in coordinates and rounding radius to closest 50km work?

[Yeetii]

Have managed to improve performance of SummitedPeaks a lot!

• Started out at 740418ms
• Paralellised calls to Peaks API brought it down to 41251ms
• Parallel calls to Strava as well as some additional internal parallelism on those brought it down to 17003ms