Speed up tuf.CheckExecutable

[RebeccaMahany]

We make 2+ calls to tuf.CheckExecutable during startup (two to verify the osqueryd binary, and zero or more to verify the selected launcher binary if updates are present). These calls can take up to 5 seconds and block startup.

@James-Pickett suggested caching the filepath, checksum, and result of executable checks so that we can avoid re-doing the checks multiple times. These could go in kv.sqlite so they're available to the lookup library on launcher startup.

[directionless]

Hrm... Under what circumstance does it take 5s, and if that happens, is it indicative of an issue?

Caching could handle corruption, and we can add in file mode.

What about stapling/gatekeeper things? Is it reasonable to assume those are cached forever, or can we only cache things on an app bundle path?

[RebeccaMahany]

Hrm... Under what circumstance does it take 5s, and if that happens, is it indicative of an issue?

@directionless a lot of the time I see executable checks time out on Windows specifically -- you suspected because of AV and that seems likely to me. So, no, probably not indicative of an issue with the binary itself.