Ble notification/indication status and timeout

[romansavrulin]

Sometimes it is useful to see if our BLE indication succeed or not. Current BLE implementation doesn't provide such functionality and has potential deadlock if indication confirmation response is not delivered to ESP by any reason.

This PR adds:

• TimedWait to FreeRTOS abstraction layer
• Indication timeout (and fix possible deadlock on semaphore)
• Indication/Notification status callback, to give precise control over messages sent to BLE peer.
• Backward codebase compatibility with previous sketches.

[chegewara]

There is no need to create additional callback, which will be created easch time you send notification/indications (memory leak).

Just use the same mechanism like with onRead/onWrite:

if(m_pCallback != nullptr){
     callback->onNotify(this);
}

[romansavrulin]

@chegewara I personally prefer to use Null object pattern to maintain KISS and DRY

It's not a big deal for performance or memory considerations with BLE data rates. But much simpler to read, isn't it?

[chegewara]

If it wont make memory leak, then ok.

[romansavrulin]

@chegewara It's a scoped variable, placed on stack. It is automatically deleted when we leave its outbound {} block ( see RAII )

[atanisoft]

for consistency it should be using the same approach as onRead/onWrite...

also this shouldn't leak any memory as it is allocated and freed automatically as part of the method execution.

[romansavrulin]

@atanisoft Did I got you right: you mean use Null object pattern in other callback checks?

[atanisoft]

The general approach used so far (in this and other libs) is:

if(m_pCallback){
     m_pCallback->onNotify(this);
}

I'm not certain your approach is any cleaner/readable. The only thing I'd suggest is use one pattern and stick to it.

[romansavrulin]

@atanisoft so, you mean readability of the code with extra

if(m_pCallback){
     m_pCallback->onNotify(this);
}

in dozen places with other 5-level conditionals is much cleaner than

callback->onNotify(this);

and we should use that approach because we used to? This doesn't sound convictive to me, sorry. I'd prefer to replace other usages of that callback to decrease overall codebase and improve maintainability.

[atanisoft]

I'm fine either way, just be consistent in usage :)

[romansavrulin]

@atanisoft Thanks, Mike