There looks to be a case where infinite recursion
is occuring when printing information about
Telecom Sessions. Set a reasonable limit of
iterations and throw a warning when this condition
occurs to better track down a root cause.

Bug: 139045282
Test: atest TelecomUnitTests:SessionTest
Change-Id: Iae69c5db070c5e58ae5d37c12d1c4df027138611

This is important for ensuring the original call direction for existing
connections added from Conference Event Packages matches the call direction
of the original calls merged into the conference.

Also moved a utility function into ConferenceParticipant from
ConferenceParticipantConnection to make it generically usable inside
Telephony.

Test: Run all unit tests.
Test: Manual testing using VoLTE conference calls with mix of MO and MT
calls; verify call logging is appropriate.
Bug: 134471046

Change-Id: Iab09397b811782ab0f876aac02070e3447d81f09

1. A previous change was made in ConnectionServiceAdapterServant to add
another parameter, requiring the user of SomeArgs.  I think this fix is
pretty self-explanatory.  (facepalm)
2. queryRemoteConnectionServices in ConnectionServiceAdapter had an issue
where the callback would not get called if there was more than one
IConnectionServiceAdapter instances.  This isn't an error condition, but
a condition where we don't query telecom for the list of valid remote
connection services.  We ensure a callback with an empty list is made
(this is similar to what Telecom already does).
This seems to be an issue inherent with DSDS because there can be multiple
SIM ConnectionServices where before there was only one.

Test: Run CTS tests.
Bug: 133639062
Change-Id: I1c508e97d1f0ea1bc72ad7ebd026c1ad66a52de3

When a device A creates a conference call containing device B and C, both
B and C can receive IMS signaling to indicate that they are in a conference
call.  This occurs on most domestic carriers; the Telephony framework
uses the "multiparty" indicator on the IMS call to switch the call to a
conference call.

We made some changes to how conference calls are logged in Q which improves
the accuracy of the call durations.  We used to log calls as they're merged
into a conference.  In the case of a participant in a remotely hosted
conference call, we'd log the call as soon as they are remotely added
to the conference.  This is unfortunate as the call durations are grossly
under-reported.

The conference call logging changes now assume we'll log the conference
event package children in the conference instead of the participants which
merge into the conference itself.  On domestic carriers, since the
call on B (or C) becomes a conference, we would then no longer log the
call.

This is FURTHER complicated because on some carriers, B and C will ALSO
receive a conference event package from the network showing all the
participants in the conference.  So if B hangs up on the conference, they
will have entries in their call log for A and C, which is really strange
because a call to C was never originated on their device.

In Telecom we need to ensure we do not log remotely hosted conference
participants, and we need to ensure that we DO log a remotely hosted
conference as if its just a single party call.

To accomplish this we need:
1. the address and name display information associated with the call from
A-B / A-C prior to the call turning into a remotely hosted conference.
We need this to log to the call log
2. the remotely hosted conference and participants need to be marked in a
manner that Telecom can identify them.

Test: Manual test.
Test: Add unit test to cover this logging scenario.
Bug: 132325382
Change-Id: I65e713f68d1695a48d96dacbf7faa4476cd8d815

Allow Telephony to mark a SIM PhoneAccount as
emergency preferred, meaning that Telecom will
override a user's PhoneAccount preference for
emergency calls if the PhoneAccount has the
CAPABILITY_EMERGENCY_PREFERRED capability.

Bug: 131203278
Test: Manual testing, Telecom/Telephony unit testing
Change-Id: I88b8bbfa444f5445b2f0d6a1542c6406a19b240f

The method queryRemoteConnectionServices had the issue that it assumes
there is a single connection manager for the device.  This assumption does
not work on a multisim device.  Since the ConnectionManager is associated
with a particular carrier, this means that the connection mgr for one
carrier could try to impact calls destined for another carrier.

This change ensures that the calling package is passed into Telecom so
that we can determine which RemoteConnectionServices which are available to
the calling connection manager.

Test: Manual test on DSDS with a connection mgr carrier and another carrier.
Bug: 131856987
Change-Id: I46d80dc68adaab7fd4374f023d7ba4242804c253