Fall back to generic info if vendor specific parser fails

[assrinivasan]

Description

This change adds some protection to the vendor specific parser function in ssd in case of any failures.

Motivation and Context

iSmart utility on Nokia-7215 is returning the following error (tested on 2 devices, 1st 202311 and 2nd 202405):

Image version: 202311

root@sonic-switch-1    :~# iSmart /dev/sda
OCI runtime exec failed: exec failed: unable to start container process: exec /usr/bin/iSmart: exec format error: unknown
root@sonic-switch-1    :~#

Image version: 202405

root@sonic-switch-2    :~# iSmart -d /dev/sda
OCI runtime exec failed: exec failed: unable to start container process: exec /usr/bin/iSmart: exec format error: unknown
root@sonic-switch-2    :~#

This error is causing stormond in 202405 images to not instantiate an SsdUtil object due to OSError:

> /usr/local/lib/python3.11/dist-packages/sonic_platform_base/sonic_storage/ssd.py(109)fetch_parse_info()
-> self.fetch_vendor_ssd_info(diskdev, vendor)
(Pdb) n
OSError: [Errno 8] Exec format error: 'iSmart'

This issue can be mitigated by adding a try-except block around the pointed line:

357         def fetch_vendor_ssd_info(self, diskdev, model):
358  ->         self.vendor_ssd_info = self._execute_shell(self.vendor_ssd_utility[model]["utility"].format(diskdev))

In cases like this, since the fetch_generic_ssd_info (which uses smartctl) will get the data first, we would at least have the first level ssd info in case the vendor specific utility fails.

How Has This Been Tested?

Tested on device with iSmart utility error and ensured that storage monitoring daemon is able to instantiate an Ssdutil object.

[mssonicbld]

Cherry-pick PR to 202405: #519