giseldo/neodataset huggingface dataset:
Replace setInterval with user events for onboarding updates

<!---
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

Improve performance by removing `setInterval` when checking for onboarding update.

## What needs to be done

Test the clearance of the `setInterval` on the both platforms (real devices) and confirm it's happening every time we navigate away from the screen or bring the app in sleep mode. On failure replace `setInterval` with other appropriate events to check for onboarding update using setTimeout with most conservative delay.

## 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.
--->


## Personas

Developers

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Replace setInterval with user events for wallet next payout updates

<!---
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

Improve performance by removing `setInterval` when checking for wallet next payout update.

## What needs to be done

Replace `setInterval` with other appropriate events to check for wallet next payout update (useFosusEffect or scroll).

## 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.
--->


## Personas

Developers

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Replace setInterval with user events for boosts updates

<!---
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

Improve performance by removing `setInterval` when checking for boosts update.

## What needs to be done

Replace `setInterval` with other appropriate events to check for boosts update (useFosusEffect or scroll).

## 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.
--->


## Personas

Developers

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Replace setInterval with user events for notifications

<!---
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

Improve performance by removing `setInterval` when checking for new notifications.

## What needs to be done

Replace `setInterval` with other appropriate events to check for new notifications (push notifications, useFosusEffect on home screen).

## QA

N/A

## UX/Design

N/A

## Personas

Developers

## 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
--->

- [ ] When receiving a push notification while app in use, the task to check for new notification should be executed
- [ ] When the home screen get focused, the task to check for new notification should be executed

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Improve tab bar navigation in all screens

<!---
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

Improve top tab bar navigation in all screens

## What needs to be done

- remove scroll indicator
- remove skeleton loaders if present
- preload data if necessary  #4618 

## QA

Not the newsfeed.

<!---
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.
--->


## Personas

Developers

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Fix screen re-render in discovery on tab navigation

<!---
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)
When in Discovery page, navigating the top bar rerender the header and navigation every time. 

### 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?

When navigating the top bar in Diacovery, the navigation and the header are rerenfered. 

### What is the expected *correct* behavior?

When navigating the top bar in Discovery, the navigation and the header should not rerenfered. 

### 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
Fix: #eb7bd819 in https://gitlab.com/minds/mobile-native/-/merge_requests/1979
(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
Remove scroll bar from top tabbar in discovery screen

<!---
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)

### 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
Improve data preload for notifications screen with react-query

<!---
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

Optimise tab rendering by preload and cache data from API.

## What needs to be done

preload and use the `all` data as cache to the rest of the filters.

## 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.
--->


## 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
--->
- [ ] Implement react query in the app
- [ ] When switching the tabs cached data must be present, followed by in-time update.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Improve bottom navigation performance

<!---
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

Improve tab bar navigation by preloading the notification screen.

## What needs to be done

Remove lazy loading screen for notifications.

## QA

Manual testing

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->


## Personas

Developers

## 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

- [ ] GIVEN that I'm on home screen
- [ ] WHEN I press the notification tab
- [ ] THEN the notification tab should open fast

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Refactor gitlab-ci.yml to accomodate new strategy

<!---
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

Refactor the gitlab-ci.yml file to accomodate the scenarios in [DOC](https://docs.google.com/document/d/1rGe5-zQ9GTh7CqnwZUp_bWRnljcvE1ThjMQvbdkRQeg/edit#heading=h.lylm18khv4vt).

## What needs to be done

- add git tags support for master branch for code-push
- intercept the version number in the tag and check if it's a patch (*.*.d)
- have the steps available for code-push to staging and separately to production 
- trigger the code-push script when either steps are selected

## 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.
--->


## Personas

Developer

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Add tag-based stages for code-push and release builds for master branch

<!---
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

Enable code-push and store release based on the git tag version.

## What needs to be done

- update gitlab-ci.yml to 
- retrieve the tag version from `CI_COMMIT_TAG`.
- create script to run conditionally based on tag version patch or major.minor
- consider testing in a separate repo for faster dev cycles.

## 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.
--->


## Personas

Developers

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
UX: in-app user verification - Intercept the code in the push notification



## Goal

Intercept the push notification, store the code for the OCR recognition and display it to the user.


Related to #4584


## What needs to be done

- [ ] Implement interceptors in the push notification service
- [ ] Add logic to intercept the in-app verification push with the code
- [ ] Display it to the user
- [ ] Capture the code to send it to the OCR logic


## QA

TBD


## UX/Design

-


## Personas

-


## Experiments

-


## Acceptance Criteria

- [ ] It should intercept the code, show a toaster and store the code locally (pass it to the OCR logic)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
SPIKE: New mobile CI/CD strategy

<!---
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

Technical analysis for the new mobile CI/CD of minds&295 

## What needs to be done

Technical analysis for the new mobile CI/CD of minds&295

https://docs.google.com/document/d/1rGe5-zQ9GTh7CqnwZUp_bWRnljcvE1ThjMQvbdkRQeg/edit#
## QA

N/A

## UX/Design

N/A

## Personas

Mobile developers

## Experiments

N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] technical analysis presented on the epic ([DOC](https://docs.google.com/document/d/1rGe5-zQ9GTh7CqnwZUp_bWRnljcvE1ThjMQvbdkRQeg/edit#heading=h.lylm18khv4vt))
- [x] future tasks built out (#4614, #4615, #4616 )

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Mobile: Update boost modal to support paying with Cash

<!---
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
--->

Adding the ability to pay for Boosts in cash will increase revenue by monetising boosts via opening boost functionality to non token holders.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Outcome from https://gitlab.com/minds/front/-/issues/5819
- Add payment selector for card payments.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Testing the end to end flow

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

To be provided from https://gitlab.com/minds/front/-/issues/5819

## 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.
--->

Yes

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Mobile app changes
- [ ] Exclude from Apple due to in-app purchase impasse 
- [ ] E2E tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Deleting / deactivating account does not log user out

<!---
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

Deleting the only account in the app, does not log user out

### Steps to reproduce

1. Create an account or have an account you can mess with
2. Delete or deactivate the account
3. Notice that you end up on account switching screen, but cannot log out, can scroll minds, but can not interact (essentially read only mode)


### Platform information

- tested Google pixel 6 pro, android 13
- iphone xr
- honor 9

### App version

- 4.29.0
- 4.30.1 (deletion) honor9
- 4.30.2 (deactivation) iphone XR

### What is the current *bug* behavior?

User not logged out when they delete / deactivate account

### What is the expected *correct* behavior?

- User should get to the "please log in" screen after deleting / deactivating account if it's only account
- User should get the username removed from account switcher after deleting / deactivating account if it's multiple accounts

### 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
Saved card won't activate unless clicked

<!---
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

Saved card won't activate unless clicked (Video recording / image bellow)

### Steps to reproduce

1. Have a card saved on your account, ready to pay for stuff
2. Try setting up supermind, or sending a wire
3. Notice you get an error message your supermind / wire could not be send
4. Click the card field, and select card
5. Notice that you can now create supermind / wire

### Platform information 

Mobile app, Android, Honor 9

### What is the current *bug* behavior?

Need to select card before sending supermind / wire

### What is the expected *correct* behavior?

If card is set up on account, it should be automatically selected.

### Relevant logs and/or screenshots

![XRecorder_02112022_224350](/uploads/843981045f18c9f289bb98452bf82bf9/XRecorder_02112022_224350.mp4)

![image](/uploads/bdbea2f63626545ebca41084d54b8534/image.png)

### Possible fixes

The default item in payment selection is not available at rendering time.

Story points: 2.0
Supermind video replies not working on ios

<!---
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 responding to a Supermind video reply on the mobile app, if you attempt to record the video directly from the Minds composer, it returns an error when you try to post the video.

### Steps to reproduce

1. Send a video reply supermind to a channel you own
2. Reply to the supermind offer on the mobile app
3. Capture a video directly using the recording tool in the composer
4. Try to post the reply and you get an error

### Platform information 

iOS.

### What is the current *bug* behavior?

- GIVEN THAT I reply to a supermind offer
- AND I capture a video directly using the recording tool in the composer
- AND I try to post the reply
- THEN the video in the reply cannot be played

### What is the expected *correct* behavior?

- GIVEN THAT I reply to a supermind offer
- AND I capture a video directly using the recording tool in the composer
- AND I post the reply
- THEN the video in the reply should play correctly

### Relevant logs and/or screenshots

![image](/uploads/df80ed44655ddf5256300b2434df2ab4/image.png)

### Possible fixes

It only happens with supermind, so i think the supermind logic does not think the video is there if its recorded directly in the app
aka you can record and post a video in the composer from regular composer.

Story points: 3.0