Ethena UStb token and minting

<br> 1. The initial limits of a new asset added to `UStbMinting` (max mint and max redeem limits per block per asset) are not accessible to off-chain observers via events because the event `AssetAdded` has only one field: `AssetAdded(address indexed asset)`. 2. Updates made via the function `setStablesDeltaLimit()` are not logged.

When orders are submitted to the functions `mint()` and `redeem()`, their field `uint128 nonce` is checked via the function `verifyNonce()`. That function uses the data structure `_orderBitmaps` to check if a sender already used or not a given nonce. In detail, it is a mapping storing for a given address a `uint256` bitmap called `invalidator` at the `uint128` keys called `invalidatorSlot`. However, the following line could lead to an issue: ``` uint128 invalidatorSlot = uint64(nonce) >> 8; ``` Casting `nonce` to `uint64` seems too restrictive. If any value of `uint128 nonce` is valid, it is possible to have two different values of `nonce` that will be stored at the same bit in the data structure `_orderBitmaps`. For instance, the two values: `nonce_a = (1 << 125) + (1 << 60)` and `nonce_b = (1 << 60)`, since any non-matching bit higher than the 64th bit will be ignored because of the cast `uint64(nonce)`. Ultimately, this could prevent valid Orders from being accepted by the contract.

It is important to validate inputs, even if they only come from trusted addresses, to avoid human error: 1. In `UStb.sol`, function `initialize()`, the address `minterContract` may not be a contract; 2. In `UStb.sol`, function `addBlacklistAddress()`, it is possible to blacklist: <br>- the minter contract and this could temporarily disrupt the mint and redeem operations; <br>- the address with the role `DEFAULT_ADMIN_ROLE`, and this could temporarily disrupt the operation to redistribute locked amounts; 3. In `UStbMinting.sol`, function `verifyOrder() `, the uniqueness and the size of `Order.order_id` is not checked; 4. In `UStbMinting.sol`, function `setUStb() `, the value of `_ustb` is not checked to be: <br>- Different from `address(0x0)`; <br>- Different from existing supported assets; <br>- Different from existing custodian;

The `UStb` and `SingleAdminAccessControlUpgradeable` contracts are designed to be upgradable. Upgradable contracts usually have reserved space to allow future versions to add new state variables to the contract without shifting down storage in the inheritance chain. As `SingleAdminAccessControlUpgradeable` is inherited by `UStb`, adding a storage gap can be done to prevent storage collisions in future updates where storage slots could be added to `SingleAdminAccessControlUpgradeable`. For instance, if in a future update, `SingleAdminAccessControlUpgradeable` is modified to include a new variable, and the `UStb` contract were upgraded to use the new version, this new variable would likely collide with the `transferState` variable in `UStb` (except in the special case where the new variable is given a custom slot).

Supporting tokens with specific features such as fees, rebasing, pausable, upgradeable, blacklist-able, or hooks on transfers could negatively impact the main flows of the system (deposits via `mint()`, transfer to custody, redeems via `redeem()`) if no specific mitigation measure is enforced to limit the consequences. For instance, in the function `_transferCollateral()` if `asset` represents an asset where the amount transferred is different than the amount requested to be transferred (ex: if fees are enforced), the actual amount transferred to custodians may differ from the expected transferred amount.