fix: fix RegisterOnChange methods for journal and db_slice

[BorysTheDev]

We have a bug with the journal->RegisterOnChange functions:

1. Start 2 tasks with traversing through the whole DB
2. The first task is already work
3. Second task do db_slice_->RegisterOnChange(db_callback)
4. After that second task do journal->RegisterOnChange(..) and yield to another fiber on the mutex JournalSlice::cb_mu_
5. during the 4th step we do LPUSH for example and db_callback save the bucket
6. we still don't have a callback for the journal so we lost data for LPUSH
7. we finish journal->RegisterOnChange(..)

This issue was reproducible in test_cluster_fuzzymigration

Also, I have fixed the issue with db_slice_->UnregisterOnChange() if it was called during callbacks processing (if the fiber yields during callback)

[romange]

Please provide a PR description. In general, I would like to ask to provide a better context for non -trivial bug fixes. See #3103 for example how @adiholden does it.

[romange]

@BorysTheDev can you also explain the fix - i.e. why shared_ptr solves the issue?

[BorysTheDev]

@romange the problem was in mutex that could yield to another fiber but prevented removing a callback during a call. So to fix the issue I need to remove mutex from RegisterOnChange, in this case, the fiber doesn't yield, but I need to prevent removing a callback so I change the vector to the list

[BorysTheDev]

to not forget, It looks we need mutex too to prevent removing some data while callback is in progress. Will think about better fix tomorrow

[romange]

LGTM from my side, will wait for Adi to approve

[adiholden]

I am not sure about the correctness of this solution.
In this change we dont have a mutex in JournalSlice::RegisterOnChange

Lets take for example the following scenario:

1. callback "LPUSH key val" is executed
2. we run db_slice callbacks for bucket holding the key
3. we give new version to the bucket holding key - version x
4. we run journal_slice callback to write journal change "lpush key val"
5. we yield when writing the journal change
6. another replica is starting calling db_slice register on change with version x+1
7. journal slice is registered on change
8. we return to fiber yield in step 5 continue iterating the journal changes list
9. we no write the journal change "lpush key val" to the stream before we serialized the bucket

[adiholden]

@BorysTheDev The changes looks good. Not sure why he ci failed here.
Also please make sure to run regression tests on you branch before merging

[kostasrim]

@BorysTheDev The changes looks good. Not sure why he ci failed here. Also please make sure to run regression tests on you branch before merging

yes and I will be merging my CI changes and we have a failure on cluster slot which I disabled manually -- keep that in mind as well