[cli] long CLI output are sometimes not printed

[Irving-cl]

Describe the bug
When I run a cli command (which has long output) twice (since I factoryreset the device) on a nRF52840 DK, the second one don't have the output printed that it should have:

> diag our-vendor-specific-command
Many many output...
Done

> diag our-vendor-specific-command
Done

The command isn't included in OpenThread public repo.

The bug is caused in this way:
In CliUartOutput in cli_uart.cpp, when sTxBuffer isn't adequate for the next writing (output for the second command), the code goes to this branch:

        else if (rval < kTxBufferSize)
        {
            while (sTxLength != 0)
            {
                otError error;

                Send();

                error = otPlatUartFlush();

                if (error == OT_ERROR_NONE)
                {
                    // Flush successful, reset the pointers
                    SendDoneTask();
                }
                else
                {
                    // Flush did not succeed, so abort here.
                    otLogWarnPlat("Failed to output CLI: %s", otThreadErrorToString(error));
                    ExitNow();
                }
            }
            rval = vsnprintf(sTxBuffer, kTxBufferSize, aFormat, retryArguments);
            OT_ASSERT(rval > 0);
            sTxLength   = static_cast<uint16_t>(rval);
            sTxHead     = 0;
            sSendLength = 0;
        }

And at this moment, after otPlatUartFlush, the underlying variable sTransmitBuffer (in ot-nrf528xx/src/src/transport/uart.c) still points to something. At the end of this block, we got:

sTxLength = length of output of the second command
sTxHead = 0
sSendLength = 0

Then at the end of CliUartOutput, Send is called. As sSendLength is 0, otPlatUartSend will be called. However, when calling otPlatUartSend, sTransmitBuffer currently is not NULL. So it will just return OT_ERROR_BUSY.
After this, we have:

sTxLength = length of output of the second command
sTxHead = 0
sSendLength = length of output of the second command

And then a few moments later, processTransmit was called, otPlatUartSendDone is called. These code are run:

static void SendDoneTask(void)
{
    sTxHead = (sTxHead + sSendLength) % kTxBufferSize;
    sTxLength -= sSendLength;
    sSendLength = 0;

    Send();
}

These steps drop the output of the second command. That's why for causing the bug.

I can think of a solution: we set sTransmitBuffer to NULL in otPlatUartFlush. I think that makes sense. After a flushing, we should be able to call otPlatUartSend with no error. Besides, we also need to add sTransmitDone = false; in otPlatUartSend in case the process was completed by processTransmit before it's really completed.

Thoughts? @bukepo @jwhui @konradderda

[EskoDijk]

I can add I had a similar problem (though in an older version of OT code) - my debug printouts were sometimes truncated.

[jwhui]

Resolved by #75