feat(api): enhance error handling and thread safety in log management

[skrashevich]

This commit introduces improved error handling in the logHandler function within the API, ensuring that any errors encountered while writing to or resetting the memory log are properly logged and communicated back to the client with an appropriate HTTP status code. Additionally, the circularBuffer struct in the logging mechanism now incorporates a mutex to ensure thread-safe operations, particularly for the Reset method which has been updated to clear all chunks and reset read/write pointers under lock protection.

The changes include:

• Logging errors and returning HTTP 500 (Internal Server Error) if writing the memory log to the response writer fails.
• Similarly, logging errors and returning HTTP 500 if resetting the memory log fails.
• Updating the HTTP method not allowed error response to set the "Allow" header correctly and use the more appropriate HTTP 405 (Method Not Allowed) status code.
• Adding a mutex to the circularBuffer struct to protect concurrent access, particularly in the Reset method which now clears all buffer chunks safely.

[AlexxIT]

1. What's the point to clear all chunks? It's a blank operation.
2. What's the point with return empty error from Reset? It's always empty, but you checking it for error in it.
3. I don't think that this error app.MemoryLog.WriteTo can happen.
4. I agree that Mutex can help. But you use it only in Reset function.

[skrashevich]

1. What's the point to clear all chunks? It's a blank operation.

for buffer state consistence in unexpected cases

2. What's the point with return empty error from Reset? It's always empty, but you checking it for error in it.

it's just best practice

3. I don't think that this error app.MemoryLog.WriteTo can happen.

"Anything that can go wrong will go wrong." © Murphy's law

4. I agree that Mutex can help. But you use it only in Reset function.

By the nature of the ring buffer, potentially it can only be required in place where buffer's internal state is modified. IMHO

[AlexxIT]

3. If we can't MemoryLog.WriteTo for some reason - we also can't write error after it.

It's all useless code. I don't see any sense in it, except http.StatusMethodNotAllowed.

[skrashevich]

some upds

[AlexxIT]

I still don't see a problem with the log code. Adding mutexes will add blocking. But without them, there are no critical problems.