MDEV-35640 Protocol_text: handle errors in allocation

[grooverdan]

• The Jira issue number for this PR is: MDEV-35640

Description

Protocol_text constructor allocated memory on an optional prealloc argument. This was along with its subclass Protocol_local.

Remove this functionality to an independent member function "allocate".

Replace two use with existing error handling on insufficient resources at the err label.

Protocol_local, that inherits from Protocol_text had one use that requested an allocation of 0. So it wasn't needed.

Release Notes

Improve memory allocation error handling in the protocol (text).

How can this PR be tested?

Adding error handling wasn't very invasive.

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[cvicentiu]

Hi Daniel,

I know I wasn't asked to review this, but here's my input:

1. True, the code did not check for errors during that "prealloc" phase, but does it actually matter?
2. The code does check for subsequent stores, if they were succesful and if not, returns ER_OUT_OF_RESOURCES. Thus, your change, even if it makes the code seemingly safer, it doesn't offer any benefit, in practice.
3. The class API is now more complex than before, where one should explicitly remember to prealloc to gain performance benefits.
4. There isn't any inherent danger in not preallocating, as the store functions handle this gracefully anyway. Nor is there anything dangerous if the preallocation failed, as long as the subsequent stores have their return values checked. Hence I consider this operation happening in a "no throw" constructor to be ok.

[knielsen]

Thanks, Daniel.

I think the patch looks ok, but let's not put it in old GA release 10.5. I would say earliest 11.4, or optionally even current development branch, at your choice.

Wrt. Vicentiu's comments, I don't really think the patch makes the api more complex, explicit pre-allocation seems nice and simple to me. And I do prefer that allocations are error-checked. But I do also agree that the issue is not super important. Just a nice cleanup patch to not have to worry about missing error check, hence good to push into main or 11.4 at the earliest.