RouteViews fetch uses wall-clock time, causing inconsistent data in coordinated runs

[pradhyum6144]

During coordinated launches, RouteViews URLs are resolved after RPKI/IRR fetching. Since participants finish at different times, they can see different CAIDA directory states as observed in bitcoin-core/asmap-data#46 where the April directory appeared mid-run.

Fix: resolve RouteViews URLs at run start, use epoch_datetime for month selection, and fall back on empty directories.

[jorisstrakeljahn]

Here's the per-participant timing breakdown from the collaborative launch logs (bitcoin-core/asmap-data#46). Since Kartograf fetches sequentially (RPKI - IRR - Routeviews), you can estimate when each participant's Routeviews request happened by adding their RPKI and IRR durations to the 16:00 UTC launch time:

Participant	RPKI	IRR	Routeviews request (ca.)	Result
achow101 (SF)	1:53	0:07	16:02	March fallback
achow101 (NY)	4:14	0:18	16:05	March fallback
Emzy	4:44	0:12	16:05	March fallback
jurraca	5:33	0:34	16:06	March fallback
fjahr	7:06	0:14	16:07	March fallback
freerko	9:00	0:18	16:09	March fallback
naiyoma	12:28	0:16	16:13	March fallback
stratospher	9:12	11:55	16:21	April data
hodlinator	30:36	11:28	16:42	April data
0xB10C	32:40	14:00	16:47	April data

The CAIDA "/2026/04/" directory appeared between 16:13 and 16:21 UTC. achow101 ran on two machines (SF and NY) and both got the March fallback.

Note that using "epoch_datetime" is a good change for consistency, especially for reproduction runs. But in the April 2 case it wouldn't have made a difference, all participants were already targeting "/2026/04/" since they were all running on April 2. The core issue was that the directory didn't exist yet at launch time and only appeared mid-run.

(Also, minor note: the issue reference should be bitcoin-core/asmap-data#46, not #46 — the collaborative launch is tracked in asmap-data, not in this repo.)

[achow101]

The gzip'd file has a timestamp of Thu Apr 2 16:13:41 2026 so that seems to line up.

Perhaps in addition to fetching based on the epoch time, we could check the timestamps of the files and only use ones that have timestamps that would only exist by the time of the epoch.

[pradhyum6144]

The gzip'd file has a timestamp of Thu Apr 2 16:13:41 2026 so that seems to line up.

Perhaps in addition to fetching based on the epoch time, we could check the timestamps of the files and only use ones that have timestamps that would only exist by the time of the epoch.

The filenames encode timestamps (e.g. routeviews-rv2-20260402-1600.pfx2as.gz) so _pick_latest_pfx2as could filter out any file with a timestamp after the epoch instead of just picking the last one. I can add that as a follow-up once the current changes are merged or as a separate PR whichever you prefer.