Lox module should re-fetch common variables from the lox authority during a session

Currently we re-fetch Lox.#pubKeys, Lox.#encTable and Lox.#constants once per session from the lox authority. The lox authority may change any of these variables, with different frequencies. From !970 (comment 3014768):

theoretically the encrypted bridge table can change every 30 minutes, which is how often rdsys sends updates to the distributors. The constants won't change often but if they do, the time estimates will be off until they are updated. And the pubkeys shouldn't change often either.

So our once-per-session approach might lead to failures, or misleading information from #constants used in getNextUnlock, especially if you have a long lasting session.

Without knowing the schedule of the lox authority, it would not be possible to know when we have to re-fetch them. Moreover, even if we were able to fetch the latest values, there is a moment of time between receiving them and using them to make another request to the authority. In principle it could become outdated again.

I think for #constants we might want to schedule a new fetch around every half a day, since it seems to only effect Lox.getNextUnlock().date.

For #encTable and #pubKeys, we may instead want to re-fetch them when a request fails. This would require:

1. Using an outdated value should either generate a failure or still work ok. In particular, it should not be possible to enter a broken state if you use the wrong value.
2. The failure should be reasonably identifiable as originating from an outdated value. In particular, we want to avoid retrying if something else is causing it to fail.

I don't know much about the lox process, so I don't know how we can achieve this. @cohosh and @onyinyang do you know what would happen if either value was outdated, and would it be identifiable?