[Epic] Refactor discussion to use Bridget API on apps

[georgeblahblah]

What needs to happen

We should refactor the discussion components so that they can use Bridget APIs instead of Discussion API on apps articles for certain functionality. This is because the apps webview doesn't have the authentication cookie or okta token for the authenticated discussion API endpoints.

Background

Discussion API

On web, the discussion API provides endpoints for the following actions:

unauthenticated endpoints

• fetch comments
• report abuse

authenticated endpoints

these endpoints are authenticated by cookie or okta auth token

• post comment
• post reply to comment
• upvote comment

On apps

The apps journey is slightly different, as the webview doesn't have knowledge of the user's identity. It doesn't have the GU_U cookie or the okta token, and so calls to the authenticated discussion endpoints will fail.

Instead, Bridget provides a discussion service which exposes some endpoints for similar functionality:

https://github.com/guardian/bridget/blob/88c99c6f311f00db6dab4daf88b9bdcf25225666/thrift/native.thrift#L122-L128

Update 12/02/24

## Tasks
- [ ] #10544
- [ ] #10325
- [ ] #10326 

[mxdvl]

Three implementations:

• [x] #10318
• [x] #10326
• [x] #10325

[georgeblahblah]

There will be a specific app version (or greater) that supports discussion with Bridget in iOS (and probably Android too), even though the Bridget API has not changed. Given the only mechanism that MAPI has is to specify a required Bridget version for a given piece of content, I suggest that we:

• release a "ghost" version of Bridget with no changes, which we bundle in the app version which implements discussion for both Android and iOS
• Specify in MAPI that articles with discussion require this "ghost" version of Bridget to be rendered with DCAR.

[georgeblahblah]

I wonder what we should do with the "sign in copy" on Discussion on apps, and more broadly, the "user is not signed in" scenario:

The current behaviour on the embedded templates is:

• no "create account or sign in" copy
• if you are not signed in and initiate a command that requires you to sign in, the app opens the sign in dialog, from which the user can also register.

Options:

• recreate the same experience as exists on the embedded templates. This would probably require a new Bridget method, as we have no way to launch the "signin/register" dialog as in the screenshot above.
• ? something else