Test timeout for settings causes unit testing to slow down unnecessary (most of the time).

Currently we have a workaround regarding settings changes during ourunit tests. See here:

https://github.com/Microsoft/vscode-python/blob/065b377a5a178f05005d62c6ce964e9ffb5105f5/src/test/common.ts#L38

This was put in to guard against upstream VSCode changes that would make settings updates non-immediate. However, while that problem has happened (and no doubt caused a lot of consternation while attempting to debug) it doesn’t mean we should pay a 2-second delay tax every time we run the tests (and what happens if the delay is > 2sec? We are no better off…).

As an alternate solution, could we simply do a spin-loop using the get command to ensure we are seeing the change?

Something like:

const expected: string = some_expected_value;
let actual: string = settings.get(key);
let counter: number = MAX_GET_TRIES; // or something like that
while (expected !== actual) {
    counter -= 1;
    if (counter < 0) {
        throw Error_Getting_Value_Exception;
    }
    await sleep(GET_SETTING_SLEEP_VAL);
    actual = settings.get(key);
}

…this way we can be alerted to a problem in VSCode as has happened in the past, but we don’t incur a 2-second delay tax for each call?

Or even more simply:

settings.update(setting, value, configTarget);
if (settings.get(setting.key) !== setting.value) {
    throw Update_Settings_Not_Immediate_Exception;
}

This way we can notify the VSCode team when we find a regression in this functionality, and either skip tests that rely on it, or enable a wait period only until the regression is corrected upstream.

cc: @brettcannon @ericsnowcurrently @DonJayamanne

[DonJayamanne]

My suggestion is simple (comment the code out)

. I would also propose that we leave the await sleep(2000); in a comment with a description of why it is there as well.

https://github.com/Microsoft/vscode-python/issues/2356#issuecomment-411614663

[DonJayamanne]

No longer required