Inconsistent storage variables cleanup during LP burning

The contract uses the following storage variables to hold the LP data:

• lp_token_to_sub_id: maps AssetId of the LP token to the SubId used to create it.
• lp_shares_per_token: maps the AssetId of the LP token with the StorageVec of LPSharesPerBin structs which represents shares owned by the LP token in each bin where liquidity was provided.
• lp_token_to_pool_id: maps the AssetId of the LP token with the PoolId, defines to which pool the given token pertains.

All the above are filled with relevant data during the LP minting process. While burning the following is being removed in the mint_utils::burn_lp_token(...):

assert(storage_keys.lp_shares_per_token.remove(lp_asset_id));
assert(storage_keys.lp_token_to_sub_id.remove(lp_asset_id));

We can see that the lp_token_to_pool_id is not removed, hence the inconsistency.

There is no impact here, as the specific AssetId cannot be re-used, yet there is inconsistent approach to data lifecycle here.

Two approaches can be considered here:

1. Removal of all data.
2. Leaving the data as is, even after burning. This approach might be considered as it will save some gas.

Fixed in commit ff06ba98bcbb6d0f999354eb67293119687c4020.