commit 62b06bcc8311977f649be52ef1eef67f5ac68f03
author Ed Tanous <ed@tanous.net> Tue May 06 13:29:48 2025 -0700
committer Ed Tanous <ed@tanous.net> Mon Jun 09 16:09:30 2025 +0000
tree 8f483daa348571f9df8ca2806cfa70f8d2400f25
parent 352ee0e1938d8858c9dcc9ad56365d6bfd52934a

Do hard close if client disobeys protocol

There are cases bmcweb might close the connection due to a violation of
the protocol.  Currently these are done gracefully, under the assumption
that a client might attempt to recover.  But this opens us up to
potentially leaving sockets open for far longer than we intend if the
client is completely gone, due to a disconnect or explicitly closing the
socket hard.

In cases where we get a protocol error, shutdown the socket hard, rather
than attempt to do things "correctly".

Tested:

I tested this MR using a script that simulated 5,000 parallel
connections simultaneously to BMC and closed them immediately without
properly sending a close_notify alert

Observations:

The BMC became unresponsive for 30-40 seconds before recovering.

After recovery, it took approximately 90 seconds to close all
connections in QEMU.
On real hardware, connection closure times may be slightly higher
(though still within expected parameters).

Conclusion:
This behavior aligns with expectations.

After 90 seconds observed that

1) No sockets in CLOSE_WAIT state

2) Able to make new connection.

```

curl -k -H "X-Auth-Token:$bmc_token" https://${IP}/redfish/v1/AccountService/Accounts
{
  "@odata.id": "/redfish/v1/AccountService/Accounts",
  "@odata.type": "#ManagerAccountCollection.ManagerAccountCollection",
  "Description": "BMC User Accounts",
  "Members": [
    {
      "@odata.id": "/redfish/v1/AccountService/Accounts/root"
    }
  ],
  "Members@odata.count": 1,
  "Name": "Accounts Collection"
}

```
Change-Id: I6ab4347efd8fda9ae86bfbb8575666ad3eabe88c
Signed-off-by: Ed Tanous <etanous@nvidia.com>
Signed-off-by: Chandramohan Harkude <chandramohan.harkude@gmail.com>