Fabric v3: Remove legacy chaincode (LSCC) support

[denyeart]

Fabric v2.x supports both the v1.x chaincode lifecycle and the v2.x chaincode lifecycle. The proposal here is to remove support for the v1.x chaincode lifecycle for Fabric v3.x.

There are many places in the code that have dual support for v1.x and v2.x chaincode lifecycle. Each of those locations will need to be assessed to remove the v1.x chaincode lifecycle support, and then the v1.x chaincode lifecycle itself will need to be removed.

[Sayalikukkar]

Hi @denyeart, I would like to contribute on this. Could you please guide me?

[denyeart]

@Sayalikukkar This will be a complex epic as the v1.x chaincode lifecycle is embedded in many places. The first thing to do would be to decompose the work into smaller issues under this epic.

@ale-linux led the work to add dual support in Fabric v2.x, so probably best to get his high level thoughts first.

[C0rWin]

@Sayalikukkar This will be a complex epic as the v1.x chaincode lifecycle is embedded in many places. The first thing to do is decompose the work into smaller issues under this epic.

@ale-linux led the work to add dual support in Fabric v2.x, so probably best to get his high level thoughts first.

Hi @denyeart, I would like to take the lead on this if you are fine. Several things have to be done to get it complete:

1. First, we need to remove it from the integration tests cause it's still being widely used there. We need to make sure to switch all places we have legacy lifecycle used.
2. Once integration tests are fixed, we can get rid of the legacy lifecycle from the NWO APIs
3. The next step would be to make sure to adhere to SDKs, to make sure it's no longer available
4. Take care of fabric samples. Almost sure it's not used, but to make sure we won't break anything
5. Remove from peer cli, so no one will be able to use it any longer
6. Refactor system chaincodes to stop referring to legacy Lifecycle APIs
7. Remove legacy.

I can prepare a more detailed plan on how to do it in small portions.

[denyeart]

Thanks @C0rWin , that would be great! Perhaps @Sayalikukkar could help on some of the tasks.

I mentioned @ale-linux because I remember there was some prior design thought around removing the old lifecycle... I've found the presentation where @ale-linux wrote this down in 2019:

• Long term we expect that LSCC will disappear
• For this reason, whenever a fabric component requires lifecycle data we have
  • Created appropriate interfaces (removing any direct access to LSCC)
  • Implemented the interface for both legacy and new lifecycle
  • Created an aggregator that uses both implementations and is used by the component
  • The aggregator often takes care of shadowing: information in the new lifecycle always takes precedence
• As soon as the legacy lifecycle disappears, we can remove the legacy implementation and the aggregator

[Sayalikukkar]

Hello @C0rWin, Let me know if anything is required from my end.

[C0rWin]

Hello @C0rWin, Let me know if anything is required from my end.

Thanks for the suggestion, I will prepare a work plan and then we can decide on how to approach it.

[C0rWin]

Thanks @C0rWin , that would be great! Perhaps @Sayalikukkar could help on some of the tasks.

I mentioned @ale-linux because I remember there was some prior design thought around removing the old lifecycle... I've found the presentation where @ale-linux wrote this down in 2019:

* Long term we expect that LSCC will disappear

* For this reason, whenever a fabric component requires lifecycle data we have
  
  * Created appropriate interfaces (removing any direct access to LSCC)
  * Implemented the interface for both legacy and new lifecycle
  * Created an aggregator that uses both implementations and is used by the component
  * The aggregator often takes care of shadowing: information in the new lifecycle always takes precedence

* As soon as the legacy lifecycle disappears, we can remove the legacy implementation and the aggregator

This is a fair plan, though, I think once we will remove all external dependencies which are still using legacy LSCC, we won't have any aggregator and will be able to proceed with the removal. Currently, the legacy is exposed via peer cli, SDKs, and inside the integration tests. Therefore, IMO we just need to start by simply removing code using legacy APIs.