Is it necessary to incorporate the length of the original plain text somewhere within the protocol?
No, as long as the final part of the message cannot be confused with the padding used, it would be possible to deterministically unpad the message. In your case, if your message cannot end with spaces then you can strip the spaces off. However, if it did anyway then the final spaces are obviously.
I sense that this is a duplicate of Is the HMAC construction really neccessary for a fixed length message?
No, that's a different question. The reason is that it talks about the HMAC itself being necessary, rather than the padding.
HMAC is build using a hash function, which is already padded internally, presuming that it has a particular block size for the message input. For SHA-2 that means that the message is padded using bit padding leaving some bytes to indicate the message size in bits.
HMAC itself already has a length indicator within the hash. But even without it: adding any data to the message would immediately change the authentication tag, so it is impossible for an adversary to add data without notice. Just to be on the safe side I would also include the padding into the hash calculation, if just to disallow length information leaking from the unpadding. But in the end, for the security of the HMAC, the padding of the plaintext message is not required; it already does that internally.
I'd make the padding / unpadding separate from any cryptographic algorithms, as you only want to validate the padding after the HMAC verification has taken place. Even then you should really take care of any operations not to leak information on the message size through side channels.
What you do seem to be talking about is padding required to hide the message size. That is different from padding for e.g. block ciphers or hash functions. The issue is here that a padding scheme must properly allow for input messages of any size. This may also mean that the padding may be more than the 255 bytes that e.g. PKCS#7 compatible padding allows for.
In that sense, it might be a good idea to include a length in case the padding is larger than 8 bytes. In that case you could set a single bit and assume the other 63 bits consist of the message or padding length. In other words: a length indicator could be more efficient than some padding scheme. OTOH, bit padding would work fine as well, with the slight disadvantage that you may need to look at all the padding bytes to find the first one that is not set to all zero / 0x80.
