## Summary
Previously, URLs shared to offline targets via the ShareActivity were
delivered to them once they became online. This change extends this
behavior to direct share targets.
## Test Plan
Test 1
* Make sure a PC device is already paired with the phone. Let's say the name of this device is "PC".
* Make PC unreachable, e.g., close the KDE app on it.
* On the phone, open Chrome and share a couple of webpages to KDE's PC's direct share target.
* Open the KDE app on the PC.
* Observe that the webpages are opened on PC.
Test 2
* Make sure a PC device is already paired with the phone. Let's say the name of this device is "PC".
* Make PC unreachable, e.g., close the KDE app on it.
* On the phone, share a file to KDE's PC's direct share target.
* Open the KDE app on the PC.
* Observe that the file is sent to PC.
Test 3
* Make sure two PC devices are already paired with the phone. Let's say the name of these devices are "PC1" and "PC2".
* Make PC1 and PC2 unreachable, e.g., close the KDE app on them.
* On the phone, open Chrome and share a couple of webpages to KDE's PC1's direct share target.
* Open the KDE app on the PC2.
* Observe that the webpages are NOT opened on PC2.
* Open the KDE app on the PC1.
* Observe that the webpages are opened on PC1.
Test 4
* Make sure a PC device is already paired with the phone. Let's say the name of this device is "PC".
* Make PC reachable, e.g., have the KDE app open on it.
* Try to share a URL from the phone to the KDE's PC's direct share target.
* Observe that the URL opens instantly on the PC.
Some Android versions seem to hang if calling sslSocket.getOutputStream()
from within the HandshakeCompleted callback (maybe because calling it in
on a socket that hasn't finished the SSL handshake is supposed to trigger
the SSL handshake).
BUG: 501241
Reading the docs, BufferedReader maybe could read and cache more than one
line from the socket, and since we discarded the BufferedReader and
created a new one (up to three times), data could be lost.
