Minor yield() cleanup: optimistic_yield, proper polledTimeout use

[dok-net]

Suggest by @devyte, this PR attempts to point out and refactor those places in cores and libraries that appear to be calling yield() more often than needed, which would hurt performance.
Please review carefully.

[earlephilhower]

Generally seems good, but I do have a style concern.

It seems to me that instead of putting in a hardcoded 10000 everywhere, a constexpr int maxyield = 10000; (or whatever name) in a header set to that would be more maintainable. I'm not fully sure there the 10ms came from or that it is the "right" number for all SDKs. Factoring it to a const that's in one place would be a much safer bet IMHO...

[earlephilhower]

The assumption of this PR is that calling yield() hurts performance.

However, this is not a multitasking system and if there's no WIFI to service or timer callbacks, a yield is almost a call-and-immediate-return. Yes, it's not instantaneous, but the chip is not going to go off and try to do something else unless there's really other work to be done.

This PR is about performance, but the changes done here are not in performance critical sections. Debug printing hex values, switching APs off and then on again, etc. If it was inside a loop run 1,000 times or something, sure, but these changes are not like that.

Removing forced yield() can change behavior. Before if I put a message into a queue that would be serviced by the OS, the yield() would ensure that queue was pumped by the OS. Optimistic_yield() means that in most cases the queue won't be pumped (unless it's been 10ms already).

So in general, I'm not seeing this as helping things in an appreciable way while introducing changes which might cause instability or non-repeatable behavior.

[dok-net]

A reply to the performance remark you made, @earlephilhower.
This sketch indicates otherwise, I think:

void setup()
{
    Serial.begin(74880);
    delay(500);
    Serial.println("opty");
    pinMode(BUILTIN_LED, OUTPUT);
    digitalWrite(BUILTIN_LED, HIGH);
}

void loop()
{
    auto ts = ESP.getCycleCount();
    for (int i = 0; i < 1000000; ++i)
    {
        digitalWrite(BUILTIN_LED, LOW);
        yield();
        digitalWrite(BUILTIN_LED, HIGH);
    }
    auto ts2 = ESP.getCycleCount();
    Serial.print("1E6 iterations over yield, ms = ");
    Serial.println((ts2 - ts) / ESP.getCpuFreqMHz() / 1000);

    ts = ESP.getCycleCount();
    for (int i = 0; i < 1000000; ++i)
    {
        digitalWrite(BUILTIN_LED, LOW);
        optimistic_yield(10000);
        digitalWrite(BUILTIN_LED, HIGH);
    }
    ts2 = ESP.getCycleCount();
    Serial.print("1E6 iterations over optimistic_yield(10000), ms = ");
    Serial.println((ts2 - ts) / ESP.getCpuFreqMHz() / 1000);
}

Result:

1E6 iterations over yield, ms = 8660
1E6 iterations over optimistic_yield(10000), ms = 2554
1E6 iterations over yield, ms = 8660
1E6 iterations over optimistic_yield(10000), ms = 2554

[earlephilhower]

Thanks for the actual performance numbers!

[earlephilhower]

LGTM, seems like a very minor change with not much impact except in, say, hexdump().