Reentrancy in solidity smart contract

Hello, I was reviewing the smart contract and noticed a common pattern where state variables are updated after external calls. This often creates a vulnerability for reentrancy attacks. To confirm this, I used Slither, a static analysis tool, to check for any potential reentrancy issues. The analysis revealed several instances where reentrancy attacks are possible. Here is a list of some of the functions where this vulnerability exists:

- [LearningToken.batchMintAttendanceToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L364)
- [LearningToken.batchMintHelpingToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L518)
- [LearningToken.batchMintInstructorScoreToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L593)
- [LearningToken.batchMintScoreToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L443)
- [LearningToken.mintInstructorScoreToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L565)
- [LearningToken.mintAttendanceToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L330)
- [LearningToken.mintScoreToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L412)
- [LearningToken.transferInstructorScoringToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L550)
- [LearningToken.transferHelpingToken](https://github.com/hyperledger-labs/learning-tokens/blob/3c087b79609e3e53eac64ab84d73e39bc659a7df/src/learning-token/contracts/LearningToken.sol#L474)

To address these vulnerabilities, the following are some of the mitigation approaches:

- Follow the Checks-Effects-Interactions (CEI) pattern, ensuring that external calls are placed at the end of functions.
- Implement a mutex lock pattern to prevent reentrant calls.
- Utilize OpenZeppelin's [ReentrancyGuard](https://docs.openzeppelin.com/contracts/5.x/api/utils#ReentrancyGuard).

OpenZeppelin's ReentrancyGuard is gas-efficient and can be implemented without interfering with the existing business logic of the contract, making it a suitable solution for this case.

Please let me know if you would like me to proceed with a pull request to address this issue.

Start with src/learning-token/contracts/LearningToken.sol at the listed functions and run Slither to reproduce the reported reentrancy findings. Review the CEI, mutex-lock, and OpenZeppelin ReentrancyGuard options; done means the reported functions no longer expose the identified reentrancy issues without changing the existing business logic.

Written by the indexing model from the issue text.