Make Connection.setExtras() thread-safe

A race condition in Connection.setExtras() can lead to a
ConcurrentModificationException. Rapid, successive AUDIO_STATE_CHANGED
broadcasts can trigger concurrent calls to setExtras() on the same
Connection instance. The method was not thread-safe, allowing one
thread to modify the mPreviousExtraKeys set while another thread was
iterating over it.

This change resolves the issue by wrapping the logic within setExtras()
in a synchronized (mExtrasLock) block. This ensures that all read
and write operations on the shared mPreviousExtraKeys member are atomic,
preventing the race condition.

This is a low-risk bug fix and does not require a flag. The
risk of a deadlock is minimal because the lock is short-lived and does
not call out to external listeners while being held, which avoids
potential re-entrancy issues.

Flag: EXEMPT thread saftey fix (low regression risk)
Fixes: 438071847
Test: none
Change-Id: I36754e11b2cc460aefd0509b220a66541753edb6