* commit 'cb0442b84a0b40bb58b0741c420970ba07c1a889':
  Tag navigation UI

Downloads are stored at a filename that is the CID computed from a SHA256 hash
of their contents.  Where necessary (such as to stream a large file down) they
are stored at the name based on the message UUID temporarily and then renamed.

Uploads, when they must be copied into our storage, are stored in the same way.

This results in de-duplicated storage, so sending the same file back and forth
many times even in different conversations results in only one copy being
stored.

Since Android does not play nice with symlinks, but we want to be able to look
up media by multiple possible hashes, the CIDs for SHA1, SHA256, and SHA512 are
all stored in a new database table whenever a file is downloaded or uploaded,
even if the file is never copied into our storage at all (so then the db table
contains a path to, say, the image in the camera folder).

When bits-of-binary cid transfer is attempted, first check if we have that
content locally already and just use it if we already have it instead of
requesting it again.

Just like a MUC, search results lack the context to be sure who sent a message,
so show the name in the result item.

* race-condition:
  Prevent race condition in loops over all bookmarks

* fix-memleak:
  Fix memory leak

Show horizontal list of tags available in current search results below the
search box, acts sort of like an autocomplete or you can just tap on it, making
tag naviation easier so you don't have to find something that matches that tag
or type it out to use it.

Can happen if we re-detect that the contact does not support command UI (or that
we don't know it does due to not being in roster / getting removed from roster)
but the session was opened using an in-message button or similar.

But do still call a full refresh on manual service discovery.

java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextNode(HashMap.java:1441)
	at java.util.HashMap$ValueIterator.next(HashMap.java:1470)

Just like a MUC, search results lack the context to be sure who sent a message,
so show the name in the result item.

Still show the close button (not a cancel button) on a completed or canceled
flow that supports prev.

* tag '2.10.10':
  version bump to 2.10.10 + changelog
  pulled translations from transifex
  bump guava library
  use custom libwebrtc (m104) for playstore release
  minor code clean up
  Use the same mechanism for link copying and linkification (#4357)
  Update recommendations for Gajim (#4355)
  Add fastlane changelog (#4354)

Prevents copying something different from what was linked, such as in the
message "fine.gif https://example.com"

* bob1:
  Preliminary support for bits-of-binary

https://xmpp.org/extensions/xep-0231.html

When a CID URI is received as part of an OOB, use bob to fetch from the sender.

This does not verify the hash at this time, nor does it "cache" for a future
send since our storage is not content-addressable yet.

* commands: (50 commits)
  Tell the server we have a UI that can handle up to 1000 items
  For very long lists, use a searchable list view
  Use a list item background that can handle being selected
  Allow nested scrolling of ListView and WebView
  NPE
  Show any commands pushed along with a message
  Allow oob webview to move the execution forward
  Spinner when loading list of commands
  Show spinner when loading if it takes awhile
  Menu item to refresh features for a contact
  Order cells by reported order
  Look more like a real web browser
  Don't submit the form when cancelling
  We can still proceed with no form, just don't send a form
  Validate presence of required fields
  DRY up common patterns for fields
  Refactor to bind to an Item container, not just a raw Element
  Use more features of the TextInputLayout
  Support more text field types
  Support reported/item tables
  ...