Add recurring handling of user, resource and vgrid map refresh to janitor

[jonasbardino]

Add recurring handling of user, resource and vgrid map refresh to janitor service. Effectively centralizes the updates in a single long-running process rather than the fragile concurrent client-initiated refreshes, since they tend to result in clients hammering the site during refresh and may leave cache inconsistent if client hits HTTP time-out in the middle of a refresh (#121).

Runs in the main thread so far, but we may need to consider a background thread/process for the refresh if it turns out to delay other janitor tasks too much.

Removes client-initiated refresh triggers in vgridman and resman backends if janitor is enabled.

Could perhaps use improved user-facing information e.g. about when the current (cached) view was generated on vgridman and resman pages to help clarify when any recent changes are not yet fully processed and showing.

[jonasbardino]

Currently fails CI due to the unrelated #353.

[jonasbardino]

Fundamentally verified in practice on a test site instance, but could use some more testing.

[Martin-Rehr]

I would prefer to let the get_X functions from 'mig.shared.vgridaccess' handle if the janitor service is enabled.

[jonasbardino]

I would prefer to let the get_X functions from 'mig.shared.vgridaccess' handle if the janitor service is enabled.

Thanks for reviewing.

If you mean keep get_X calls unchanged in vgridman and resman when janitor is enabled that will most likely cause the existing cache issues to remain or even grow as the janitor will then only join the thrashing. I've elaborated on the motivation in the PR description.

[Martin-Rehr]

I would prefer to let the get_X functions from 'mig.shared.vgridaccess' handle if the janitor service is enabled.

Thanks for reviewing.

If you mean keep get_X calls unchanged in vgridman and resman when janitor is enabled that will most likely cause the existing cache issues to remain or even grow as the janitor will then only join the thrashing. I've elaborated on the motivation in the PR description.

I ment changing the get_X from mig.shared.vgridaccess into a wrapper and change the original get_X into eg. _get_X and let mig.shared.vgridaccess.get_X check if the janitor service is enabled, for example:

def get_vgrid_map:
        if configuration.site_enable_janitor:
            (vgrid_map, _) = load_vgrid_map
        else:
            vgrid_map = _get_vgrid_map

[jonasbardino]

I would prefer to let the get_X functions from 'mig.shared.vgridaccess' handle if the janitor service is enabled.

Thanks for reviewing.
If you mean keep get_X calls unchanged in vgridman and resman when janitor is enabled that will most likely cause the existing cache issues to remain or even grow as the janitor will then only join the thrashing. I've elaborated on the motivation in the PR description.

I ment changing the get_X from mig.shared.vgridaccess into a wrapper and change the original get_X into eg. _get_X and let mig.shared.vgridaccess.get_X check if the janitor service is enabled, for example:

def get_vgrid_map:
        if configuration.site_enable_janitor:
            (vgrid_map, _) = load_vgrid_map
        else:
            vgrid_map = _get_vgrid_map

Considering the number of other places the get_X_map functions are called where the caller may or may not care about janitor presence I think that would potentially introduce quite a few regressions elsewhere. On the other hand those callers could also still interfere like the existing issue so it's probably a good point 👍 ... something to look into.

Meanwhile I added PRs #371 and #372 to introduce fundamental unit tests for the mig.shared.vgrid and mig.shared.vgridaccess modules to help assure their correctness.