Do not switch screens when clicking 'Remove podcast'

[gitstart]

Issue

Closes #5909

Steps to reproduce

Currently, removing a podcast from within the podcast or from the Subscription list in the sidebar (but not from the Subscriptions screen) ends with the user being shown the Episodes screen.
In addition, the user is taken to the Episodes screen even before they have confirmed they actually want to remove the podcast.

Issue Video:

https://www.loom.com/share/34ba40d96dd244e99c25f3b6c11af722

Video After Fix:

https://www.loom.com/share/ed3abd70e03c4f07aedfb663145ed513

---

This code was written and reviewed by GitStart Community. Growing future engineers, one PR at a time.

[ByteHamster]

As it is now, this basically reverts de8496f, which was added deliberately to fix a bug. There need to be additional changes that avoid crashes here.

[gitstart]

Thank you @ByteHamster for reviewing the PR,

Implementation in this PR is bit different from the implementation mentioned in comment, please have a look at following difference.

In this PR callback triggered as soon as user confirms deletion before actual deletion from DB while in the implementation you shared in link callback triggers after actual deletion process.

I also tried with that implementation and faced crash but with current implementation i tested with 45+ subscriptions and crash did not appeared.

Thank you again..!!

[ByteHamster]

In this PR callback triggered as soon as user confirms deletion before actual deletion from DB

The callback is called before actual deletion, but I doubt Android completely destroys the fragment synchronously before deletion starts. Or does it? The fragment either needs to be completely destroyed before deleting or the fragment needs to be able to deal with the case that its own podcast gets deleted.

[gitstart]

In this PR callback triggered as soon as user confirms deletion before actual deletion from DB

The callback is called before actual deletion, but I doubt Android completely destroys the fragment synchronously before deletion starts. Or does it? The fragment either needs to be completely destroyed before deleting or the fragment needs to be able to deal with the case that its own podcast gets deleted.

Thank you @ByteHamster for reviewing this,
Regarding, the fragment gets destroyed before deletion and stops listening for events, so in this implementation we don't observe a crash, while if we add callback after deletion the destroy process and update UI (Fragment listen to event) process takes places simultaneously or during updating fragment get destroyed and crash appears.

[ByteHamster]

Regarding, the fragment gets destroyed before deletion and stops listening for events

Is this just an observation that you make by looking at logs or is it actually specified to be that way?