feat(Log): Add macros for conditional log print and rc handling

[thekurtovic]

• Defined variants of the logging macros which print only if a condition is met.
  • These macros should be preferred over placing log statements inside a simple if-block (i.e. rc != 0).
• Defined a variant of the error log macro which takes in rc and implicitly appends "; rc=%d %s" to the format string in order to display return code and string representation via NimBLEUtils::returnCodeToString.
  • Prints only if rc != 0.

[thekurtovic]

There's a couple of spots where a log print will be surrounded by a simple if-check on a rc value.

if (rc != 0) {
    NIMBLE_LOGE(LOG_TAG, ...);
}

I thought it would be nice to have a macro for such cases to keep things a bit more clean going foward.
NIMBLE_LOGE_IF(rc != 0, LOG_TAG, ...);

What do you think?

---

Then could standardize these wrapper functions like so:

bool NimBLEDevice::deleteAllBonds() {
    int rc = ble_store_clear();
    if (rc != 0) {
        NIMBLE_LOGE(LOG_TAG, "Failed to delete all bonds; rc=%d", rc);
        return false;
    }
    return true;
}

into

bool NimBLEDevice::deleteAllBonds() {
    int rc = ble_store_clear();
    NIMBLE_LOGE_IF(rc, LOG_TAG, "Failed to delete all bonds; rc=%d", rc);
    return rc == 0;
}

RC to string handling

NIMBLE_LOGE(LOG_TAG, "Connection failed; status=%d %s", rc, NimBLEUtils::returnCodeToString(rc));

into

NIMBLE_LOGE_RC(rc, LOG_TAG, "Connection failed; status=%d", rc);

[h2zero]

Looks nice! We could probably add this part into the macro as well status=%d

[thekurtovic]

Did a quick check and rc=%d seemed to be more common than status=%d.

[h2zero]

Looks good to me!

[thekurtovic]

Hm seems like I did something wrong.
Commit history shows the one from this PR plus another one for "Merge pull request #301 from thekurtovic/feat-log-condition".
Sorry 😅 I'm guessing I was supposed to choose squash and merge, or rebase and merge?
I managed to fix it locally by doing git rebase master~2 but didn't bother attempting git push -f

[h2zero]

Ahh, no worries lol. I always rebase locally then push -f to the branch before merge but for others PR's I use the rebase and merge option and or squash

[thekurtovic]

There's no way to resolve it through the github web ui is there? I see a "revert" button but it seems like that will just create more commits...
If you don't mind rebasing it at some point, I'd feel less dumb 🤐I regret not practicing on a test repo lol

[h2zero]

A merge commit isn't going to hurt anything, it's just not my preference. Next time just do a squash to a single commit or however many you want and rebase to master from there. Then you can force push to your branch (carefully lol). After that there will be a straight line for the history. Oh and use the rebase merge option on GitHub, if the button goes grey then you know you need to do the above process.