RDKB-64487: Code changes for Mutex locking and deadlock prevention

[AravindanNC]

Reason for change: Replace global plMutex with per-profile lookup optimization. Add deadlock prevention by lock hierarchy enforcement.
Test Procedure: Build RDKE image

Signed-off-by: nc.aravindan@gmail.com

[Copilot]

Pull request overview

This PR refactors locking in the bulkdata profile and XConf profile implementations to reduce contention and prevent deadlocks by moving from a single global mutex to more structured locking (rwlock for the profile list, dedicated mutex for XConf), and by documenting an intended lock hierarchy.

Changes:

• Replaced the global profile list mutex with profileListLock (pthread_rwlock_t) and updated call sites.
• Introduced a documented lock hierarchy and added a per-profile profileMutex field.
• Renamed XConf’s global mutex to xconfProfileLock and updated the XConf thread/condition-variable synchronization to use it.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 11 comments.

File	Description
source/bulkdata/profilexconf.c	Renames and re-scopes XConf locking to xconfProfileLock and updates the report thread synchronization logic.
source/bulkdata/profile.h	Documents a lock hierarchy and adds profileMutex to Profile.
source/bulkdata/profile.c	Migrates from a single mutex to profileListLock (rwlock) and updates many code paths accordingly.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

source/bulkdata/profilexconf.c:243

• reportInProgress is written under xconfProfileLock in CollectAndReportXconf() (e.g., profile->reportInProgress = true;) but read under singleProfile->reportInProgressMutex in ProfileXConf_uninit() and ProfileXConf_notifyTimeout(). Using different mutexes to guard the same flag breaks synchronization and can introduce data races (especially ProfileXConf_uninit() which does not hold xconfProfileLock when reading). Please make reportInProgress consistently protected by a single lock (ideally the same mutex used with reuseThread’s condition variable) and update all accesses accordingly.

        /* Set reportInProgress flag to prevent concurrent report generation
         * and profile deletion while we're working. This must be done under
         * xconfProfileLock to prevent races with ProfileXConf_notifyTimeout() and
         * ProfileXConf_delete().
         */
        profile->reportInProgress = true;