ProtocolId Registry

[franzns]

Discussed this with @markusbkoch and decided to put down some thoughts about the ProtocolId Registry in an issue for any future developments of linear pools:

In general, the idea of having a protocol Id in the Linear pools (specifically in the ERC4626 linears) is for the user (SDK, frontend, backend, api, etc.) to be able to identify the underlying protocol. This can be used mainly for two purposes:

1. Displaying the underlying protocol in the UI
2. APR retrieval as the protocol ID can be mapped to an APR source by the user.

First of all, this feature is completely unused currently. Neither the frontend, nor the SDK or the backend make use of it.

I only stumbled on the ProtocolId Registry by accident. When investigating it, I found a few drawbacks which make me reluctant to integrate it:

1. No backwards compatibility: We still need to deploy a different strategy for any of the old linear pools
2. It relies on a multisig (even governance?) to add new protocol IDs to the registry which is manual, slow and can lead to errors.
3. Also creation of linear pools is manual and can lead to mistakes. Having a linear pool with the wrong protocol ID leads to handling error-cases in the user code.
4. Some protocols don't have the same source for all their APRs, e.g. reaper uses a different source for their single strats and their multi strats. This would need two protocolIds created for them.

While I do like having as much data as possible onchain and also query data from there, above points make me still use hardcoded tokens addresses. It let's me keep full flexibility although it is more work to add new tokens for a protocol.