GeezerVison

populateCacheWith created the pmr vector for the object, which matches
the output route and looks up its transport, for every FetchOp. On a
cache hit the vector is never used, and the analysis CCDB fetcher issues
one FetchOp per column for every row of the source table. Create it
only where an object is actually requested from the server.

When a CCDB table has no separate uniformity column, the analysis CCDB
fetcher called populateCacheWith for every row of the source table, so
about 19k times per timeframe for a BC-indexed table such as the ones of
propagation-service-v2, even though consecutive BCs share the same
millisecond timestamp. Reuse the previous responses whenever the lookup
key, the uniformity value or else the timestamp, is the same as the one
of the previous row. Since the key determines every FetchOp of the row,
the responses and hence the output table are unchanged.

For the LHC25b4a6 AO2D of Hyperloop test 799098 this is about 350 runs of
equal (millisecond) BC times over 1.17M BCs in 61 DFs, instead of one
query per BC.