Options here were: make the get-token thread try to return a unit, or
write a different thread to check whether GCP Storage seemed to be
configured and poll on that thread, or move the whole thing into a Gall
app.
The compromise between time-to-implement and overall cleanliness seemed
to be to write a different thread that just checks whether the settings
fields have been poked. Unfortunately this means GcpManager is now a
somewhat hefty JavaScript state machine.
Took out the logic to check whether S3 was configured in GcpManager,
since it was really only there to prevent spamming the console with
500s. If you have both S3 and GCP Storage configured for some reason,
you will now use GCP per the logic in useStorage.
It turns out 'devstorage.read_write' also gives us an access token
instead of a JWT, and is probably more the thing that we want.
Took the opportunity to make scope a macro to clean up the make-jwt call
site.
The expiry field we get from Google is not a timestamp, but a count of
seconds after which the token is invalid (hence, 'expires_in'). We
represent this as a @dr by multiplying the integer we get from Google by
~1s. (Perhaps it will wind up being easier on the Landscape side to
consume the raw integer, but we may as well start off more
type-correct.)
Also cleans up some names now that I'm less confused about how the token
API works, and makes some syntax more vertical.
The correct scope to ask for is not devstorage.editor, but
cloud-platform. This will, rather than returning a signed JWT from
Google that looks like it works but doesn't, return a JSON object
containing an access token and expiration time.
Moves =, closer to call sites so it's clearer what's coming from where.
Also uses +ot, allowing a less horrifying +sign-jwt. This also seems to
not jump back and forth between tapes and cords as much, for what that's
worth.
