* Removed the unnecessary query to download manager for previous downloads. Now we are only making request to active downloads which are in our download DAO.
* Removed the foreground service from application since now download manager handles the notification so we don't need the foreground service.
* Removed the all code related to notification management.
* After implementing the previous approach to track download progress during network fluctuations, a new issue occurred. Sometimes, when the user pauses a download, it resumes immediately without any user interaction. To address this, we introduced a new field to track the paused status, distinguishing whether the pause was initiated by the user or caused by the DownloadManager due to network fluctuations.
* Downloads paused due to network errors like "Waiting to Retry" are now resumed automatically when the network becomes available.
* For downloads configured to only proceed on Wi-Fi, the application will resume progress when a Wi-Fi connection is re-established. Similarly, downloads queued for mobile networks will resume when the mobile network reconnects.
* Previously, if a download was stopped due to a network error and the Download Manager was waiting to retry, we were not receiving updates from the Download Manager. As a result, the download progress was not being displayed when the app was reopened.
* Improved the service start mechanism: If the application is in the background, we now avoid starting the service because foreground services cannot be started when the application is not in the foreground.
* Moved the `Book()` object creation to `lifeCycleScope` instead of running it on the main thread. Earlier, it was blocking the UI, especially with large ZIM files. Now, by using `lifeCycleScope`, it won't block the main thread.
* Improved the KiwixServer creation process. Server creation was previously happening on the main thread, which could cause the same issue we are facing with adding bookmarks. Because we are creating the same book object while creating the server, which is required for `server` creation.
* Updated the behavior of the "Starting server" dialog. Before, the dialog disappeared after validating the IP address, even though server creation was still in progress. Now, the server creation process is moved to the IO thread. For large ZIM files, server creation can take some time, so the dialog will only dismiss once the server is successfully created or if an error occurs. This ensures users are aware that server creation is in progress.
* Moved the cancel download logic to the IO thread, ensuring that download-related tasks are performed on the IO thread while keeping the main thread free.
* Also moved the functionality to the IO thread for checking the status when we receive the ACTION_DOWNLOAD_COMPLETE broadcast from DownloadManager, to determine if the download was successful or canceled. This ensures it doesn't block the main thread, as cancelDownload is currently causing a blockage.
