commit c0fff6ab6fbd86a36a39f49d686207f7ac70426c
author manukh <manukh@chromium.org> Fri Jul 22 15:23:06 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Jul 22 15:23:06 2022
tree 4507fda7fdb47e03b2d3b74dd85d923eda420432
parent bb49224adba9d1ca1637c6beef1c8c0541c4b8df

[memories][persist-clusters] `HistoryClustersServiceTaskUpdateClusters`.

Adds a `HistoryClustersServiceTaskUpdateClusters` class, similar to the
existing `HistoryClustersServiceTaskGetMostRecentClusters`.

Both are extensions of the `HistoryClustersService` that encapsulate
some of the callback functions to avoid polluting the
`HistoryClustersService`'s namespace.

Whereas `HistoryClustersServiceTaskGetMostRecentClusters` iterates
recent visits 1st and is intended for getting clusters for the UI and
keyword cache, `HistoryClustersServiceTaskGetMostRecentClusters`
iterates oldest visits 1st and persists the new clusters to be used by
`HistoryClustersServiceTaskGetMostRecentClusters`.

E.g.,
    Day:          1 2 3 4 5 6 7 8 9 10
    Is clustered: C C C C C C U U U U

`HistoryClustersServiceTaskGetMostRecentClusters` will 1st cluster the
unclustered days, 1 day at a time; i.e. day 10, then 9, then 8, then 7.
Then it will switch to returning the existing clusters; i.e. day 6, then
5, ... then 1.

On the other hand, `HistoryClustersServiceTaskGetMostRecentClusters`
will start at the clustered threshold (day 6 to 7 boundary), and cluster
and return days 5-7 inclusive, then 6-8, then 7-9, then 8-10.

Currently, `HistoryClustersServiceTaskGetMostRecentClusters` is used. In
a followup CL, it will be invoked periodically, e.g., capped at once
every N hours and triggered by user input or a timer.

Bug: 1184879, 1184875, 1171352
Change-Id: I4f5a7a6eccdc61464e92f2cf712934867806e33c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3752843
Reviewed-by: Tommy Li <tommycli@chromium.org>
Commit-Queue: manuk hovanesian <manukh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1027240}