User should not have to wait that cache is recreated before login in at instance startup

[greenscientist]

The following code is in the startup path:

    // Batch calculation jobs require the cache to exist. It should not be
    // possible to run those without the cache, so we wait for its creation
    // before allowing users to connect
    if (_booleish(process.env.STARTUP_RECREATE_CACHE)) {
        console.log('Recreating cache files');
        // TODO get cachePathDIrectory from params
        await recreateCache({ refreshTransferrableNodes: true, saveLines: true });
    }

    // Enqueue/resume running and pending tasks
    // FIXME This implies a single server process for a given database. We don't
    // know if the job is enqueued in another process somewhere and may be
    // executed twice. For pending jobs, we could have a first run, first serve,
    // but for jobs in progress, we don't know if they are actively being run or
    // not
    if (process.env.STARTUP_RESTART_JOBS === undefined || _booleish(process.env.STARTUP_RESTART_JOBS)) {
        await ExecutableJob.enqueueRunningAndPendingJobs();
    }

It should be done in the background, while still letting the user come in. We should not start any calculation before this is done, but users should be able to use the interface.

[tahini]

This was done to make sure that the cache was always present when the application is available, so we don't have to manage if it's there or not, because the next block makes enqueues previously running tasks and when they run, the cache has better be there.

I don't like the idea of needing an extra mechanism to make sure calculations are ready and having to wait for it. But if it can be done cleanly and be transparent to calculation tasks, then I guess I can be convinced.

[greenscientist]

The biggest issue in the code path is recalculating all the transferable nodes. Maybe that could be skipped now, isn't everything in the DB ?

[greenscientist]

Also something seems off with the promise in the code path. We should be able to send more calculation to OSRM in parallel, it's just IO. Probablement we have an extra await somewhere.