Add <class ThreadsStreams> object from Mashey tap-slack variant

[WayneBanksy]

The current version of tap-slack fails to sync a parent message with all of its children. The method to execute this request from the API can be found in tap-slack/streams.py file (lines 153 - 172).

The mashey tap-slack variant (updated 16 months ago) has these lines of code under the same class object in the streams.py file lines 359 - 401 and should be added to the meltano-labs variant. It creates a full-table that has the sync of the parent message with all of its replies.

@tayloramurphy not sure who else should be tagged here!

[tayloramurphy]

@pnadolny13 @aaronsteers y'all know more about the SDK at this point than I do. Since this is basically about adding a new parent / child stream, the code would probably be much simpler than what @WayneBanksy is proposing here, right?

[aaronsteers]

@WayneBanksy - Can you explain this a bit more for me?:

The current version of tap-slack fails to sync a parent message with all of its children...
It creates a full-table that has the sync of the parent message with all of its replies.

I'm not sure I follow - can you add an example with an explanation of what is currently not included that should be? Thanks!

• Mashey: https://github.com/Mashey/tap-slack/blob/master/tap_slack/streams.py#L372-L401
• MeltanoLabs: https://github.com/MeltanoLabs/tap-slack/blob/main/tap_slack/streams.py#L169-L172

[aaronsteers]

Doing a little more digging, I see @tayloramurphy's point above. Some of the code here could in theory be replaced with a simple parent-child relationship, specifically that would be replacing the direct invocation pattern from the parent Messages stream:

• Messages.post_process() calls Thread sync directly: https://github.com/MeltanoLabs/tap-slack/blob/main/tap_slack/streams.py#L111-L124
• And the custom property Messages.threads_stream_start seems similar to the inbuilt "signpost" feature in the SDK: https://github.com/MeltanoLabs/tap-slack/blob/main/tap_slack/streams.py#L98-L101

Cc @stkbailey - Who probably has more context on the design decision and any "gotchas" he ran into during dev:

The threads stream is directly invoked by the Messages stream, but not via
standard parent-child relationship. Instead, parsed messages that have a
more recent "last_reply_at" timestamp will have a FULL_TABLE sync performed.

[stkbailey]

I'm rusty on the specifics, but the design was inspired very much by Airbyte, which actually has a good explanation on the strategy here: https://github.com/airbytehq/airbyte/blob/e8eb7dbe0678149c0e1cc2d1e5ed4938601dbb82/airbyte-integrations/connectors/source-slack/source_slack/source.py#L204

The problem with the parent-child relationship is that threads can continue to have messages for days after the sync of the top-level message. So to determine whether any children need to be synced, you have to scrape through a few days of Slack messages once again.

But @WayneBanksy are you saying you aren't getting any data from the Threads endpoint? Have you tried extending the thread_lookback_days parameter?

tap-slack/tap_slack/tap.py

Line 43 in f0205cd

th.Property(