The Restriction Manager does not completely implement ERC1404 which leads to account that are supposed to be restricted actually have access to do with their tokens as they see fit
Audit: 2023-09-centrifuge-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/token/RestrictionManager.sol#L28-L34


# Vulnerability details


## Impact

Medium, contract's intended logic is for _blacklisted_ users not to be able to interact with their system so as to follow rules set by regulationary bodies in the case where a user does anything that warrants them to be blacklisted, but this is clearly broken since only half the window is closed as current implementation only checks on receiver being blacklisted and not sender.

## Proof of Concept

The current implementation of the ERC1404 restrictions within the `RestrictionManager.sol` contract only places restrictions on the receiving address in token transfer instances. This oversight means that the sending addresses are not restricted, which poses a regulatory and compliance risk. Should a user be `blacklisted` for any reason, they can continue to transfer tokens as long as the receiving address is a valid member. This behaviour is contrary to expectations from regulatory bodies, especially say in the U.S where these bodies are very strict and a little in-compliance could land Centrifuge a lawsuit., which may expect complete trading restrictions for such blacklisted individuals.

Within the `RestrictionManager` contract, the method `detectTransferRestriction` only checks if the receiving address (`to`) is a valid member:

[RestrictionManager.sol#L28-L34](https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/token/RestrictionManager.sol#L28-L34)

```solidity
function detectTransferRestriction(address from, address to, uint256 value) public view returns (uint8) {
    if (!hasMember(to)) {
        return DESTINATION_NOT_A_MEMBER_RESTRICTION_CODE;
    }
    return SUCCESS_CODE;
}
```

In the above code, the sending address (`from`) is never checked against the membership restrictions, which means blacklisted users can still initiate transfers and when checking the transfer restriction from both `tranchtoken.sol` and the `liquiditypool.sol` it's going to wrongly return true for a personnel that should be false

See [Tranche.sol#L80-L82)](https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/token/Tranche.sol#L80-L82)

```solidity
// function checkTransferRestriction(address from, address to, uint256 value) public view returns (bool) {
//     return share.checkTransferRestriction(from, to, value);
// }
```

Also [Tranche.sol#L35-L39](https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/token/Tranche.sol#L35-L39)

```solidity
    modifier restricted(address from, address to, uint256 value) {
        uint8 restrictionCode = detectTransferRestriction(from, to, value);
        require(restrictionCode == restrictionManager.SUCCESS_CODE(), messageForTransferRestriction(restrictionCode));
        _;
    }
```

This function suggest