feat: add PoolFees RtApi & AccruedFees event

[wischli]

Description

• Adds Accrued event for fixed fees when they are updated (either manually during NAV update or during epoch
  closing)

Accrued {
	pool_id: T::PoolId,
	fee_id: T::FeeId,
	pending: T::Balance,
	disbursement: T::Balance,
},

• Adds PoolFees Runtime API list_fees which simulates a PoolFees update and returns the list of pool fees divided by the bucket

fn list_fees(pool_id: PoolId) -> Option<PoolFeesList>

type PoolFeesList<...> = Vec<PoolFeesOfBucket<...>>;

pub struct PoolFeesOfBucket<FeeId, AccountId, Balance, Rate> {
	/// The corresponding pool fee bucket
	pub bucket: PoolFeeBucket,
	/// The list of active fees for the bucket
	pub fees: Vec<PoolFee<AccountId, FeeId, PoolFeeAmounts<Balance, Rate>>>,
}

• Adds Pool Fees update to execution of previous epoch

Runtime API

Apps needs to add type decorations for the new PoolFeesApi similar to the existing ones.

Checklist:

• I have added Rust doc comments to structs, enums, traits and functions
• I have made corresponding changes to the documentation
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works

[lemunozm]

Clean and straignforward!

Just a minor question and NIT

[lemunozm]

NIT. This type is very long. Could maybe get_pool_fees() return a type which simplifies this?

[wischli]

Since clippy is complaining, I should do that yes. I dislike introducing types specifically for runtime API responses because these have to be typed manually in the JS side.

[lemunozm]

Oh, I didn't know that. And with tuples, they do not need to specify any type?

[lemunozm]

Maybe you can get the best of both worlds with a type alias?

[wischli]

In JS, tuples are just arrays. So you have to specify them as tuples still. WDYT about 731aaa1?

[lemunozm]

Perfect!

[lemunozm]

LGTM