We always update the eauth endpoint based on new logins from the local
identity. We also let the user configure a hardcoded endpoint url. In
both cases, we update a recency timestamp for the endpoint, to help us
keep our scry namespace responses immutable.
However, we even updated this timestamp if the visible endpoint didn't
change. That is, if the new value was identical, or if the auto-detected
endpoint changed, but it was actively being overridden by a
user-configured url.
Here, we update the stored timestamp only if the visible url actually
changed. This should help us respond to (remote) scry requests more
consistently.
(See also the note in +send-keen.)
Now support scrying into eyre to retrieve & display its known cache
entries.
Also adds a little extra logic that lets the dbug agent send cache clear
commands on the user's behalf.
To avoid needlessly long scrolling, we add an "open" property to the
debug dashboard's SearchableList, which can be set to false to collapse
the list by default. This is useful for eyre's debug page, which
commonly contains very long lists.
Include the cached responses in their own named mass section, and add a
scry endpoint that produces the entire current cache.
A follow-up commit will leverage this for showing it in the debug
dashboard.
The restructuring in #6852 put everything under versioned scry paths.
Arvo remains none the wiser and still happily scries for /whey, without
a leading version number, resulting in loss of detail for gall's section
in |mass output.
Here, we simply slap the current version number in front of the /whey
scry path, to get it to resolve.
If the cache entry for any given url was cleared, eyre would recognize
that an entry was bound at some point in the past, and serve a 404,
instead of falling back to the normal, cacheless, dynamic response.
Here, we make eyre serve from the cache only if there is a full cache
entry for the url, and have it proceed into normal request handling
logic otherwise.
This way, setting a cached response for some url no longer means giving
up dynamic responses on that url for the rest of time.
Recent versions of vere exhibit the same behavior. As such, in practice,
this code won't get hit without a similarly-patched version of the
runtime.
