Implement buffered file writer with concurrency support

You are given a simple file writer class that writes data directly to disk:

class FileWriter {
public:
 // Append `data` to the file on disk immediately (no buffering).
 // May be relatively slow because it calls the OS for each write.
 void write(const std::string& data);

 // Flush any OS-level buffers to disk.
 void flush();
};

This class is already implemented for you — you do not need to implement its real file I/O. Each call to FileWriter::write is relatively expensive because it goes to the OS, so the goal of this exercise is to reduce how often it is called.

Constraints & Assumptions

• FileWriter::write and FileWriter::flush are the only operations you may call on the underlying writer; their signatures are fixed and non-virtual.
• buffer_capacity is given in bytes.
• All input strings passed to write are reasonably small compared to buffer_capacity.
• Memory allocation does not fail.
• Single-threaded for Part 1; concurrent (multiple threads) for Part 2.

Clarifying Questions to Ask

• Should the capacity-triggered flush call flush() on the underlying writer (durability) or only forward the bytes (batching)? — i.e. what exactly does "flushed to the underlying FileWriter" mean versus "flushed to disk"?
• Is the threshold inclusive — flush when the buffer is >= buffer_capacity, or strictly >?
• Am I allowed to modify the FileWriter interface (e.g. make its methods virtual), or must it stay exactly as given? This affects how I can write test doubles.
• What should happen if a single write is larger than buffer_capacity, or if buffer_capacity is 0?
• For Part 2: what ordering guarantee is required across concurrent calls — full serialization, or just data integrity (no corruption / loss)?

Part 1: Implement a buffered file writer

Implement a BufferedFileWriter that uses an internal in-memory buffer to reduce the number of calls to the underlying FileWriter. Composition is preferred over inheritance (BufferedFileWriter has-a FileWriter).

class BufferedFileWriter {
public:
 BufferedFileWriter(FileWriter& underlying, size_t buffer_capacity);

 // Append `data` to an in-memory buffer.
 // Only when certain conditions are met (e.g., the buffer is full),
 // data should be flushed to the underlying FileWriter.
 void write(const std::string& data);

 // Force all currently buffered data to be written to the
 // underlying FileWriter and then flush it to disk.
 void flush();
};

Behavior:

1. The constructor receives a reference to an existing FileWriter and a buffer_capacity in bytes.
2. write(data) appends data to an internal buffer; if after appending the buffer size is greater than or equal to buffer_capacity, it writes the buffered data to the underlying FileWriter and clears the buffer.
3. flush() writes any remaining buffered data to the underlying FileWriter (only if non-empty), then calls flush() on the underlying FileWriter.

Also write (or describe) unit tests that validate:

• Writing data smaller than buffer_capacity, then calling flush().
• Writing multiple chunks that together exceed buffer_capacity, asserting data is forwarded at the right times.
• Calling flush() multiple times with an empty buffer is safe.

What This Part Should Cover

• Correct buffering logic: >= threshold, clearing the buffer after forwarding, and a no-op forward when the buffer is empty.
• The distinction between forwarding bytes and durably flushing (capacity trigger forwards but does not fsync; flush() does both).
• Composition over inheritance, with the underlying writer held by reference.
• Tests that assert timing/behavior (data withheld until flush; capacity trigger does not fsync), not just final concatenated bytes — which forces a deliberate, working test-double strategy.

Part 2: Make BufferedFileWriter thread-safe

Now assume BufferedFileWriter may be used from multiple threads concurrently — different threads may call write() and flush() at the same time. Extend your design so it is thread-safe, and provide pseudocode (any language) showing how shared state is protected and how write() and flush() coordinate.

Clarifying Questions for this Part

• What durability scope must flush() guarantee for writes that are racing with it (started but not yet returned) versus writes that completed before flush() was called?
• Is byte-on-disk order required to match the order in which write calls returned, or only that each write's bytes land contiguously?
• Is a dedicated background-flush thread or a max-buffer backpressure limit in scope (these would justify a condition variable), or is a synchronous design sufficient?

What This Part Should Cover

• A precisely stated thread-safety guarantee (what is and is not promised) before any code.
• A single mutex guarding all access to the buffer, with the critical section covering the full append-and-conditionally-forward sequence.
• An argument for why this is race-free (no torn buffer, no lost/duplicated bytes, each forwarded chunk is exactly one thread's accumulated buffer).
• Awareness of the I/O-under-lock cost and the buffer-swap optimization with its ordering caveat; recognizing a plain mutex suffices and a condition variable is only needed for waiting.