Unnecessary cluster response processing when destroying channel

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 7.0.X, Master
• Fix Version/s: 7.0.0 DXP FP37, 7.0.0 DXP SP7, 7.0.5 CE GA6, 7.0.X, 7.1.0 M1, 7.1.X, Master
• Component/s: Fault Tolerance > Clustering Framework, Performance
• Labels:
  • ee-ts
  • liferay-digital-enterprise-70-sp7
  • liferay-fixpack-de-37-7010
• Branch Version/s:
  7.0.x
• Backported to Branch:
  Committed
• Fix Priority: 3
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/54437

Description
When calling the ChannelHubManagerUtil#destroyChannel method, a ClusterRequest is created to call the same method on other nodes. The ClusterRequest is not set to fireAndForget, meaning that the node that sent the request awaits a response from the receiving node. However, this method returns void, and as far as I can tell, there is no possibility of an exception being thrown by ClusterExecutorUtil#execute, even if the ClusterNodeResponse has an exception. Therefore, there is no reason not to set the ClusterRequest to fireAndForget. By setting it to fireAndForget we can avoid some unnecessary waiting by the node that sent the request, as well as some unnecessary processing by the node that received the request.

This also can lead to unnecessary INFO [default-40][ClusterExecutorImpl:497] Unable to get response container for [UUID] messages occasionally appearing in the logs, depending on the timing of when the JVM's garbage collector decides to clean out the no-longer referenced objects in the _futureClusterResponses map. Since the thread sending the request lets go of its reference to the FutureClusterResponses, the JVM's garbage collector can potentially remove the entry from the map before the ClusterNodeResponse is processed by its thread, triggering this if block

Steps to Reproduce
N/A.