[Status Bar] Use `defaultDataSubId` flow to trigger config re-fetch.

The root cause of b/285298304 is that, because no downstream work was
collecting on the `defaultDataSubId` flow *directly*, that flow was
never starting. So, we were never listening for
`ACTION_DEFAULT_DATA_SUBSCRIPTION_CHANGED` intent and were not
re-fetching the config when the default subscription changed.

However, this bug was masked by the `config_subIdChangeEvent_updated`
test, which was incorrectly passing. It was passing because
FakeBroadcastDispatcher was sending the
`ACTION_DEFAULT_DATA_SUBSCRIPTION_CHANGED` intent to the
`carrierConfigChangedEvent` receiver, even though that receiver did
*not* match the intent.

This CL:
1) Updates FakeBroadcastDispatcher to send intents only to receivers
   that match the intent.
2) Updates `config_subIdChangeEvent_updated` test to use the new
   FakeBroadcastDispatcher method, causing the test to fail.
3) Updates MobileConnectionsRepositoryImpl to collect on
   `defaultDataSubId` flow directly, causing the test to pass again.

Fixes: 285298304
Test: atest MobileConnectionsRepositoryTest#config_subIdChangeEvent_updated
Change-Id: I007751b4a6279569311362cd14410f053a6a47f2