Update v2.4.0 release notes

Update v2.4.0 release notes

Signed-off-by: David Enyeart <enyeart@us.ibm.com>

release_notes/v2.4.0.md

@@ -1,39 +1,52 @@
-v2.4.0 Release Notes - <Date TBD>
-=================================
+v2.4.0 Release Notes - November 29, 2021
+========================================
 
 New features
 ------------
 
-**[FABGW-1] Fabric Gateway**
+**Fabric Gateway**
 
-Hyperledger Fabric v2.4.0 contains the new Fabric Gateway feature.
+Fabric Gateway is a new service running on peer nodes that manages transaction submission and processing for client applications, with the following benefits:
 
-The Fabric Gateway is a new component that will implement much of the high-level 'gateway' programming model in the Fabric peer,
-enabling the removal of much of the transaction submission and query logic from client applications, and shifting it to a common gateway component running within the Fabric peer.
-The various client SDKs can therefore be slimmer, more consistent, and require less maintenance.
+* Simplifies client applications and SDKs - Your client application can simply delegate transaction submission to a trusted peer. There is no need for your application to open connections to peer nodes and ordering service nodes from other organizations.
+* Fabric Gateway manages collection of transaction endorsements from other organizations and submission to ordering service on behalf of client applications.
+* Fabric Gateway has intelligence to determine what endorsements are required for a given transaction, even if your solution utilizes a combination of chaincode-level endorsement policies, private data collection endorsement policies, and state-based endorsement policies.
 
-The Fabric Gateway will also simplify the administrative overhead of running a Fabric network because client applications
-will be able to connect and submit transactions via a single network port rather than the current situation where ports
-have to be opened from a client application to multiple peers across potentially multiple organizations.
+New lightweight Gateway SDKs (v1.0.0) are available for Node, Java, and Go. The SDKs support flexible application patterns:
 
-The Fabric Gateway is delivered along with slim SDKs in the [https://github.com/hyperledger/fabric-gateway](https://github.com/hyperledger/fabric-gateway) repository.
-Check out the [client application samples](https://github.com/hyperledger/fabric-gateway/tree/main/samples).
+* You can utilize the high level programming model similar to prior SDK versions, allowing your application to simply call a single SubmitTransaction() function.
+* More advanced applications can leverage the gateway's individual Endorse, Submit, and CommitStatus services for transaction submission, and the Evaluate service for queries.
+* You can delegate transaction endorsement entirely to the gateway, or if needed, specify the endorsing organizations and the gateway will utilize a peer from each organization.
 
-**[FAB-11334] Unjoin a channel from a peer**
+For more information, see the [Fabric Gateway documentation topic](https://hyperledger-fabric.readthedocs.io/en/latest/gateway.html).
+
+**Unjoin a channel from a peer**
 
 The new command `peer node unjoin` enables an administrator to remove (unjoin) a channel from a peer.
 The peer must be stopped when the command is executed so that channel artifacts can be cleaned up.
 The channel's blockchain, state database, and associated entries will be removed from the peer.
 When the peer is restarted it will no longer receive blocks for the channel.
 
+For more information, see the [peer node command reference](https://hyperledger-fabric.readthedocs.io/en/latest/commands/peernode.html#peer-node-unjoin).
+
+**Calculate package ID of a packaged chaincode**
+
+You can calculate the package ID from a packaged chaincode without installing the chaincode on peers using the new `peer lifecycle chaincode calculatepackageid` command.
+This command will be useful, for example, in the following cases:
+* When multiple chaincode packages with the same label name are installed, it is possible to identify which ID corresponds to which package later.
+* To check whether a particular chaincode package is installed or not without installing that package.
+
+For more information, see the [peer lifecycle command reference](https://hyperledger-fabric.readthedocs.io/en/latest/commands/peerlifecycle.html#peer-lifecycle-chaincode-calculatepackageid).
+
+
 Improvements
 ------------
 
-**peer and orderer - Implement legacy name constraints verification for Go 1.15**
+**peer and orderer - Implement legacy name constraints verification for Go 1.15 and above**
 
 These changes reproduce the Go 1.14 name constraint verification in the MSP.
 Without these changes, certificate chains that would fail verification in Go 1.14 would
-successfully validate in Go 1.15 due to the change mentioned in the [Go 1.15 release notes](https://golang.org/doc/go1.15#commonname).
+successfully validate in Go 1.15 and above due to the change mentioned in the [Go 1.15 release notes](https://golang.org/doc/go1.15#commonname).
 Specifically, if a signing certificate contains a name constraint, the leaf certificate
 does not include SAN extensions, and the leaf's common name looks like a host name,
 then the additional verification is performed to ensure deterministic behavior relative
@@ -54,7 +67,7 @@ no peer in the organization gossips blocks to any other peer in that organizatio
 Use this setting when all peers pull blocks from ordering service. For more
 information see deprecation announcement below: **FAB-15317: Block dissemination via gossip is deprecated**.
 
-**orderer - [FAB-18484] Return transaction forwarding result back to the client synchronously**
+**orderer - Return transaction forwarding result back to the client synchronously**
 
 With this improvement a Raft follower waits for the transaction to be forwarded to the Raft leader,
 and returns the result (success or failure) back to the client accordingly.
@@ -70,26 +83,46 @@ Since chaincode.externalBuilders is an array, it previously was not possible to
 It is now possible to override chaincode.externalBuilders using an environment variable
 using the format `CORE_CHAINCODE_EXTERNALBUILDERS=[{name: x, path: dir1}, {name: y, path: dir2}]`.
 
+**peer and orderer - Make gRPC maximum message size configurable**
+
+This improvement makes gRPC maximum message size configurable in peer and orderer.
+Previously the maximum message size was hardcoded to 100 megabytes.
+Since all nodes should be consistent it is recommended to keep
+the default value of 100 megabytes for MaxRecvMsgSize & MaxSendMsgSize.
+The value can be configured if needed however.
+Configure in peer core.yaml with `peer.maxRecvMsgSize` and `peer.maxSendMsgSize`.
+Configure in orderer orderer.yaml with `General.MaxRecvMsgSize` and `General.MaxSendMsgSize`.
+
 
 Fixes
 -----
-All fixes as of v2.3.2 are included in v2.4.0. Additionally, the following fixes are made in v2.4.0.
+All fixes as of v2.3.3 are included in v2.4.0. Additionally, the following fix is made in v2.4.0.
 
-**orderer - [FAB-18521] Consenters' metadata is not replicated while OSN catches up with snapshot**
+**orderer - Fix bug when an orderer crashes at channel creation**
 
-If an ordering service node crashes while replicating blocks from another ordering service,
-the consenters metadata will not be available and the ordering service node will not be
-able to reconnect to the consenter set upon restart. This fix ensures that an ordering
-service node that is replicating blocks persists the consenters metadata so that it
-can reconnect to the consenter set.
+This fix handles a scenario where an ordering service node crashes during channel creation.
+Previously the ordering service node would attempt to re-create the channel upon next startup,
+resulting in a panic with the following error:
+"Error creating chain support: error creating consenter for channel: failed to restore persisted raft data: failed to create or read WAL: failed to open WAL: fileutil: file already locked".
 
 
 Dependencies
 ------------
 Fabric v2.4.0 has been tested with the following dependencies:
 * Go 1.16.7
 * CouchDB v3.1.1
-* Alpine images 3.13
+
+Fabric docker images on dockerhub utilize Alpine 3.14.
+
+Deprecations (new)
+-----------------------
+
+**Ordering service system channel is deprecated**
+
+v2.3 introduced the ability to manage an ordering service without a system channel.
+Managing an ordering service without a system channel has privacy, scalability,
+and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
+For information about removal of the system channel, see the [Create a channel without system channel documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.3/create_channel/create_channel_participation.html).
 
 Deprecations (existing)
 -----------------------