add parameter for limiting maximum AOF files size on disk

[kronwerk]

one can optionally want to limit AOF disk usage not with disk real size, but with some tailored value. this PR makes it possible.
possible use cases:

1. filling disk up with AOF to the real limit may break something in user's environment (logs, watchdogs, anything) - setting lower value prevents that completely;
2. setting this new limit to some low value may allow automatic solving of filling disk problem for those users who don't care too much about disk cost:

• intense writes may overcome automatic AOF rewrite with some user's settings at some moment;
• AOF reach lower than full disk limit (e.g. 50-60% of disk);
• eventually automatic AOF rewrite comes in once more and finally fixes that.
  while on 100% filled disk (like nowadays) that automatic solution is impossible due to insufficient space for tmp AOF rewrite files (0 space, actually) - one should size up disk under running database which makes some people a bit nervous, as I noticed, and in some cases that's not always convenient or even possible.

Fixes #540

[codecov]

Codecov Report

Attention: Patch coverage is 84.61538% with 2 lines in your changes missing coverage. Please review.

Project coverage is 70.90%. Comparing base (1acf7f7) to head (b57409c).
Report is 17 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/aof.c	85.71%	1 Missing ⚠️
src/server.c	83.33%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1425      +/-   ##
============================================
+ Coverage     70.71%   70.90%   +0.19%     
============================================
  Files           119      119              
  Lines         64652    64625      -27     
============================================
+ Hits          45717    45822     +105     
+ Misses        18935    18803     -132     

Files with missing lines	Coverage Δ
src/config.c	77.59% <ø> (-0.06%)	⬇️
src/server.h	100.00% <ø> (ø)
src/aof.c	81.25% <85.71%> (+1.12%)	⬆️
src/server.c	87.48% <83.33%> (-0.09%)	⬇️

... and 43 files with indirect coverage changes

[xbasel]

The error message:
Error writing to the AOF file: <ENOSPC>
is misleading if the issue is not actual disk space but hitting the configured max file size. Consider logging a more explicit message, and using EFBIG instead of ENOSPC for clarity.

[kronwerk]

I thought about smth like that, but haven't found a better error code than ENOSPC. the one you offered is (https://man7.org/linux/man-pages/man2/open.2.html):
EOVERFLOW pathname refers to a regular file that is too large to be opened. The usual scenario here is that an application compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 tried to open a file whose size exceeds (1<<31)-1 bytes; see also O_LARGEFILE above. This is the error specified by POSIX.1; before Linux 2.6.24, Linux gave the error EFBIG for this case.

seems that it's more misleading (imho) - we're not opening a file, we're writing to it, and we're exactly out of space (though the limit is not a real disk limit).

we can try to define our own errno type, a new one, to differ it from the real disk limit and form a more descriptive message based on that upper in code stack - but shouldn't that be an overkill for such an issue?

[xbasel]

POSIX error codes aren't tied to specific system/library calls and can be applied broadly. In the example above, it was in the context of open. Applications can use their own interpretations, this is an example:
https://github.com/valkey-io/valkey/blob/unstable/src/module.c#L5427

I'm fine with using either error codes, but there should be a custom error message to avoid misleading users into thinking it's a real disk space issue if ENOSPC is used.