Liquid Collective - Solana

The `AddToAllowlistEntry` and `RemoveFromAllowlistEntry` instructions have the following constraint for the `allower` signer value: ``` address = state.allower @ ErrorCode::OnlyAllower ``` However, the `allow_list_entry` account passed to both instructions only has the following constraint for its seeds: ``` seeds = [b"allow_list_entry", args.stake_pool.as_ref(), args.user_account.as_ref()] ``` This effectively means that a valid `state` has to be passed to the instruction and that the `allower` that signs the transaction has to be that state's allower. However, this also means that, as long as the allower passes a valid `stake_pool` account and a valid `user_account`, they can add/remove said user account to/from the allow list for the referenced stake pool. As a result, any account that has `allower` access to any state can add and remove users from any arbitrary stake pool they desire.

The following functions do not validate public key values before setting them, resulting in setting/resetting account identifiers to the default public key if it is sent in the transaction. This is similar to the lack of zero address checks issue in Solidity code bases. - The `new_pauser` key in `processors::set_pauser::exec()` - The `new_allower` key in `processors::set_allower::exec()` - The `admin`, `allower`, `pauser`, and `initial_manager` keys in `processors::initialize::exec()`

The `FeeArgs` struct consists of two parts, a `numerator` and a `denominator`, representing the two parts of a fraction. There is currently no validation that the `denominator` part of the struct isn't a zero, which may lead to unwanted consequences and potential reverts if an invalid `FeeArgs` is sent in transactions.