giseldo/neodataset huggingface dataset:
Move Search indexer to pulsar entities-ops

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
Move the SearchIndexer and Cleanup queues over to pulsar stream

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Remove the old SQS queue (keep the runner code until we are on production)
- Introduce a new runner for the new subscription
- Cleanup old cold for submitting events to SQS

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Extensive QA is required

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->
Developers :nerd: 

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Pulsar is used for search indexing

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Fix boost rankings on sandbox

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Fix boost rankings on sandbox

### Steps to reproduce

(How one can reproduce the issue - this is very important)

### Platform information 

(Browser, device, system stats, screen size)

### What is the current *bug* behavior?

(What actually happens)

### What is the expected *correct* behavior?

(What you should see instead)

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Cannot access private property Minds\Core\Boost\V3\Models\Boost::$guid

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Error in Sentry trying to access private property - symptoms unknown but could extend to broken pagination or boost loading.

### Steps to reproduce

https://minds-inc.sentry.io/issues/3922300366/?project=1538020&query=is%3Aunresolved&referrer=issue-stream

### Platform information 

Web

### What is the current *bug* behavior?

Unknown - error in Sentry

### What is the expected *correct* behavior?

Should not be an error in Sentry

### Relevant logs and/or screenshots

https://minds-inc.sentry.io/issues/3922300366/?project=1538020&query=is%3Aunresolved&referrer=issue-stream

### Possible fixes

Change to `getGuid()`

Story points: 1.0
Boost feed unnecessary calls in newsfeed

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

(Summarize the bug encountered concisely)

### Steps to reproduce

(How one can reproduce the issue - this is very important)

### Platform information 

(Browser, device, system stats, screen size)

### What is the current *bug* behavior?

(What actually happens)

When loading the newsfeed we are making 2 calls to the boost feed endpoint fetching the same data from both.

### What is the expected *correct* behavior?

(What you should see instead)

Optimise the logic to avoid making unnecessary calls to the boost feed endpoint.

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
New boosts are showing in feed for Minds+ members who have disabled boosts

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Make sure that users who pay for Minds+ and have boosts "DISABLED" do not see any boosts anywhere on Minds.


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Make sure that users who pay for Minds+ and have boosts "DISABLED" do not see any boosts anywhere on Minds.

Example for https://minds.com/jack 

Settings:
![Screen_Shot_2023-02-06_at_10.25.24_AM](/uploads/f3e51e3a3097544d83193273b04c0d91/Screen_Shot_2023-02-06_at_10.25.24_AM.png)

Seeing Boost in Feed:
![Screen_Shot_2023-02-06_at_10.25.12_AM](/uploads/e8406c61df1866269ce82ada3cebebb7/Screen_Shot_2023-02-06_at_10.25.12_AM.png)


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

If a user is active Minds+ and has Boosts disabled in Boost Settings, then they should not see any boosts in any feeds on either web or mobile.


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

None needed.

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

Should get fixed with backend change but need to confirm.

## Personas

<!---
Who does this user impact and why (optional)
--->

Minds+ customers.

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

None.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Minds+ customers with boosts disabled should not see boosts anywhere on Minds (web and mobile)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Record sidebar boost views

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
Record the sidebar boost views when the endpoint is called

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
See above

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->
Boosters

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Sidebar boost view events are fired when sidebar boosts are requested

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Denormalise channel served boost views

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
Create an efficient way to retrieve aggregated channel served views so that we can attribute these to users at a later date

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
See goal above

### Vitess

| Column | Description |
| ------ | ------ |
| served_by_user_guid       | PRIMARY KEY       |
| boost_guid | PRIMARY KEY |
| views | integer |
| last_viewed_timestamp | timestamp |

### Daily job

```sql
SELECT served_by_user_guid, SUM(views) as total_views_served, SUM((payment_amount / views) * 1000) as ecpm
FROM boosts_partner_views a
INNER JOIN boosts b ON a.boost_guid = b.guid
WHERE status = 9
AND DATE(completed_timestamp) = :ref_date
GROUP BY served_by_user_guid

```

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
Add feature flag to control paying rewards flow

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Spike task for calculating eCPM for a channel serving boosts
- [ ] Build out business rules
- [ ] Iterator and partner earning deposits implemented in https://gitlab.com/minds/engine/-/blob/master/Core/Monetization/Partners/Manager.php

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 13.0
Add views to pulsar topic

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
To enable other services to consume our views we should submit our views to a new pulsar topic

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Create a new pulsar topic we emit views to

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
N/A

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
N/A

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Views are being submitted to a pulsar stream
- [ ] Match the data payload to be client_meta/snowplow equivalent  

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Missing push/in app notifications for when boost is completed

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

When a boost is completed no push or in app notification is sent.

### Steps to reproduce

1. Open app
2. Login successfully
3. create a boost
4. Wait for it to complete
5. notice that no notification is thrown from backend

### Platform information 

Web and mobile-staging

### What is the current *bug* behavior?

No push/app notification on boost completed

### What is the expected *correct* behavior?

Push/app notifications should appear

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Flag reported entities with matching boosts with a REJECTED status

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

Remove content with upheld reports from the boost queue and reset auto-approvals.

## What needs to be done

When a strike is applied to an entity, check if there is a boost of that entity - if there is, flag that boost as `REJECTED` status.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

How should REPORTED entities appear in the boost console.

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Do not allow auto-approval of users who have strikes
- [ ] Update the Business Logic spreadsheet to match this criteria
- [ ] When a boost is reported and accepted by an admin, reject boosts and use a new Report Reason
- [ ] Make sure the feat flag for https://gitlab.com/minds/engine/-/merge_requests/1237 is ON when we deploy, providing we want to enable it.

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [ ] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Boost console should be sorted by boost time - newest first

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

To ensure the sorting on boost console for admin and user - should be sorted by boost time - the newest boosted should show up on top. 

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

New boost console 4638 flag

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] sort by boost time - newest one on top

The below screenshot is how it looks now and needs to be fixed:

![1B47E540-7B47-458B-A739-CB317FB48490](/uploads/1d32d7ead2553e574aae92de46a0030d/1B47E540-7B47-458B-A739-CB317FB48490.jpeg)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Error case handling for new boost console


### Summary

When you do not have enough tokens and boost a post, should throw correct error message. Currently it says internal server error.

***This applies to both cash and token boost.

### Steps to reproduce

1. Open app
2. navigate to boost console with feature flag on
3. Create a new post
4. boost this post and choose more tokens/cash then you have.
5. Once you press the boost button, internal server error shows up.


### Platform information 

Mobile 4.31 v48 staging

### What is the current *bug* behavior?

Internal server error appears

### What is the expected *correct* behavior?

Proper error message must appear instead of internal server error

### Relevant logs and/or screenshots

![7797C2BF-5AD4-4F1B-BB7A-0471D2CDC4BC](/uploads/4f3ee9fa3a550af94ce93fb749e085d5/7797C2BF-5AD4-4F1B-BB7A-0471D2CDC4BC.jpeg)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Aggregate boost v3 views and display to users

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Allow users to see how well their boost is doing by summarising their boosts performance in a condensed table

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Update the boost_summary table to include the necessary information. Present this information to the users. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Boost views should show in the console.

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
N/A

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

A future ticket can be made to show the views. 

## Personas

<!---
Who does this user impact and why (optional)
--->
Boosters

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Boost views are stored in the boost_summary table

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Support the new clustered recommendations in discovery 'top'

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Following on from https://gitlab.com/minds/data-science/minds-etl/-/issues/40, the API should deliver these new recommendations

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Update the queries to match the new schemas (from https://gitlab.com/minds/data-science/minds-etl/-/issues/40)
- Ensure the deranking of seen posts still works
- Users with no cluster ID should still receive recommendations


### Sample query

```sql
select
    recommendations_cluster_activity_map.*
from
    minds.recommendations_user_cluster_map
    inner join minds.recommendations_cluster_activity_map on
        recommendations_user_cluster_map.cluster_id = recommendations_cluster_activity_map.cluster_id
where
    user_id = 100000000000000063
order by
    cluster_id,
    _valid_from desc,
    score desc
limit 200
;
```

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Recommendations are delivered. 

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

N/A

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->

users

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

Yes, a new flag needs to be made. `engine-2494-clustered-recs-v2`

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] The clustered recs endpoint is reading from the new tables
- [ ] Seen posts are deranked
- [ ] There is a feature flag

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0