Deprecation of UiPoolDataProviders / UiIncentiveDataProviders

[sakulstra]

The two contracts UiPoolDataProviders and UiIncentiveDataProviders are inherently problematic for integrators.

Most importantly:

• they break on every upgrade, making them not very easy to use
• they are not deployed as part of the protocol, but by the maintainers of aave/interface who have their own release cadence (e.g. on aave v3.2 the version in address book was simply non functional for 10 days till it got updated). To make matters worse, some integrators now rely on a private fork of ours of the ui-pool-data-provider which we used for dash as it was deployed before avara deployed the 3.2 instances - our version isn't better and also breaks on each upgrade(just fetches a bit more data, which is even worse in every case).
• as pool upgrades never happen exactly at the same time across networks due to chain synchronisation times, even if the new providers were deployed, you need to exactly time the replacement on each network to not have a downtime on your interface
• testnets usually are not 100% in line with mainnets, so the uipooldataproviders are not actually equal

After the 3.2 upgrade we looked at a lot of integrator code and the reality is that they don't like the providers because of the issues mentioned before, but also because:

Lack of documentation

Upgrades happen randomly without announcing (e.g. 3.1 broke at some point because virtualBalance was added)
The code itself is the least documented thing on the aave-origin repo with not a single test touching it.

Over-fetching

1. Every more or less decent app knows after one call what the symbol/name/decimals and addresses(underlying a/v) of a reserve are. Most integrations we checked even store that info in some sort of backend or similar(not sure exactly how they keep in sync, we didn't see the backend implementation - i guess events or polling).
   So refetching these things on every call is wasteful and part of the reason why when benchmarking these calls are extremely slow.
2. These providers are built for aave/interface, same as the utilities. The use-case is not the same between integrations built on top and the interface. E.g. a leverage protocol built on top might only care about wstETH/WETH rates, but has zero interest in other reserves and no interest at all in things like unbacked, isolation/silo or irparameters. The only thing they might want is the rates of the two assets -> the current utils and providers force them to fetch & calculate everything though.

---

I think as long as there is no alternative to e.g. only fetch & calculate the current rate, providers need to stay part of the repository. Longer term though i think it makes sense to provide some finer grained utilities built on top of the native procoldataprovider. In case of 3.2 upgrade, there was no reason for any app to break due to stable debt removal - noone used stable rate already.

Bottom line is that the current state is not very good for users/consumers due to the reasons mentioned above.
More fine granular integration docs should be provided somewhere and rely on non breaking core components like the pdp - no custom contract that breaks on every upgrade.