NOJIRA: refactor redux connect to hooks

[spirosdi]

What does this do?
It modernizes from older-style pattern React-Redux connect API to modern useSelector/useDispatch hooks.

Why are we doing this? (with JIRA link)
Moving to useSelector and useDispatch leads to cleaner, more maintainable, and performant application, aligning with the modern React development paradigms. More precisely:

• Simplicity and Readability : The useSelector and useDispatch hooks allow you to extract state and dispatch actions directly within your component, which can make the component logic easier to follow compared to the connect function which introduces additional complexity with higher-order components.
• Direct Access to Redux State and Actions : With hooks, you directly use state and dispatch within your component, which leads to improved performance and responsiveness as your components only re-renders when relevant state changes.
• Less Boilerplate : There's no need to create mapStateToProps and mapDispatchToProps functions. The whole HOC container component can be removed.
• Future-proof : The React community is moving towards hooks as a standard for handling state and side effects in functional components. Adopting hooks makes it easier to adopt future React features as they evolve.

For more details please check: https://redux.js.org/tutorials/videos#modernizing-a-legacy-redux-application-with-react-hooks.

How should this be tested? Do these changes have associated tests?
No associated tests needed.

Dependencies for merging? Releasing to production?
No dependency.

Has the application documentation been updated for these changes?
Not necessary.

Did someone actually run this code to verify it works?
@spirosdi using herbarium.collectionspace.org as backend.

[spirosdi]

@mikejritter , This is a placeholder PR. While it can be merged as it stands, we can extend it by applying changes to additional components.

I wanted to clarify whether there is a specific reason for using the connect API instead of the useSelector and useDispatch hooks.

Refactoring to hooks requires converting all class components to functional components, which can be not so straightforward. Therefore, I propose that we take a first step by applying the refactoring to the components that are already functional. This can be done in the scope of the current PR. Later on we can refactor class components to functional and then refactor to hooks.

Do you have any concerns about this approach?

[mikejritter]

@spirosdi This is something I've wanted to do for a while now, and had started on when initially updating to React 16 but never had time really put time into. The use of connect is really just because the codebase was started before hooks were available. I was looking at updating to the a more recent version of redux-toolkit as well, I just wanted to close out the last dev cycle before making changes.

As far as how to approach it, I was thinking similarly - migrate components which are already functional then start to look at what else can be easily migrated. I was thinking of taking small pieces at a time, e.g. doing the routes/pages, then some subset of components, etc. I guess it depends on how many changes there are and trying to keep that manageable for review.

[spirosdi]

@mikejritter , thank you for your feedback, sounds good! I will then check which components are already functional and migrate them. I will do it in the scope of this PR. Hopefully it doesn't get too large to review. If so, I will break it in smaller PRs targeting this one.