Make backfilling a thread optional

[carsonfarmer]

For extremely large/long threads, it may not be ideal to actually walk back in history. Some clients may want to only join and get new updates. This is particularly the case for things like real-time feeds or data, where thread content can become quite long. This has some implications for certain types of blocks (like joins), so requires some serious thought.

[sanderpick]

Makes sense. This and #537 are related to #264 in that thread progress needs to be stoppable, resumeable, and now opt-out-able.

Related, we should use different HEADs for:

• peer membership (joins and leaves)
• content (files and messages)
• annotations (comments, likes, ignores and flags)

Will open an issue for that.

[andrewxhill]

In mobile, we are using the accept apis https://github.com/textileio/go-textile/blob/master/mobile/invites.go#L52

Perhaps in the short term we could let the client specify how far back to walk? Right now, long-ish threads are fairly broken in mobile.

A pattern I'm seeing is that,

1. You join a large thread with many old blocks
2. The node begins the join process and you sort of have access to the thread
3. but because you haven't created a join block, nobody else knows you are there so they aren't going to send you new blocks
4. you can't leave the thread as the node seems to get mixed up since it is still walking back

related

https://github.com/textileio/go-textile/issues/704 https://github.com/textileio/go-textile/issues/537