Always create base AOF file when redis start from empty.

[chenyang8094]

See issue #9794

Force create a BASE file (use a foreground rewriteAppendOnlyFile) when redis starts from an empty data set and appendonly is yes.

The reasoning is that normally, after redis is running for some time, and the AOF has gone though a few rewrites, there's always a base rdb file. and the scenario where the base file is missing, is kinda rare (happens only at empty startup), so this change normalizes it.
But more importantly, there are or could be some complex modules that are started with some configuration, when they create persistence they write that configuration to RDB AUX fields, so that can can always know with which configuration the persistence file they're loading was created (could be critical). there is (was) one scenario in which they could load their persisted data, and that configuration was missing, and this change fixes it.

Add a new module event: REDISMODULE_SUBEVENT_PERSISTENCE_SYNC_AOF_START, similar to
REDISMODULE_SUBEVENT_PERSISTENCE_AOF_START which is async.

Note: This PR initially also disabled BGREWRITEAOF when appendonly config is no, but that part was later removed to be discussed separately.

[chenyang8094]

Add some of my comments at the top:

I'm not sure if disabling BGREWRITEAOF while AOF is off will cause problems for existing users, it's a big breaking change after all. I hope that people who have this usage scenarios can submit them so that we can immediately discard this PR

This will also affects the way some tests , For example if you want to test whether aofrewrite of a data type is correct, Before this you can do:

r bgrewriteaof
waitForBgrewriteaof r
r debug loadaof

Regardless of whether redis-server is started with appendonly yes configuration

But now you should force set appendonly yes in advance , or the test will faild.

So I changed a lot of existing tests that depended on this way.

Ironically, if I executeconfig set appendonly yesin advance, it will trigger an AOFRW itself, but to make the test more straightforward, I still have to execute the BGREWRITEAOF command separately

[oranagra]

haven't reviewed the tests yet.

[oranagra]

i agree it's a good idea to remove the change about blocking BGREWRITEAOF from this PR.
please mark all the comments that where related to the reverted changes as resolved, and please post your comments about the use case or existing users for that in #9794

[soloestoy]

I'm happy that we keep BGREWRITEAOF, avoid a breaking change, it's useful in many scenarios.

[oranagra]

@soloestoy we removed it from this PR to be discussed separately, but i'm not sure we reached a decision yet.
can you please write some post in the other issue about who's using it (what that change would break), and which are the many scenarios it's useful for.

[ShooterIT]

Hi @oranagra @soloestoy IIRC, some users actually use this feature 😂, AOF is easy to inject to another redis server when running, such as by nc , but RDB is needed to parse, enabling AOF may cause performance loss, so they execute BGREWRITEAOF when needed.

[oranagra]

@ShooterIT thank. can you move that message to #9794 (we took that content out of this PR)