Adapt net interface delete to 'rockstor' service null config default

[phillxnet]

Almost all services have a default config of null: including the Web-UI service known as 'rockstor'. However when deleting an existing interface, with a default null config for the 'rockstor' service: we get the following log entry indicating a silent failure in our fencing to guard against inadvertent removal of the Web-UI associated 'management' interface.

[26/Mar/2024 14:56:39] ERROR [storageadmin.views.network:564] the JSON object must be str, bytes or bytearray, not NoneType
Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/storageadmin/views/network.py", line 560, in delete
    config = json.loads(so.config)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/json/__init__.py", line 339, in loads
    raise TypeError(f'the JSON object must be str, bytes or bytearray, '
TypeError: the JSON object must be str, bytes or bytearray, not NoneType

---

See the following reproducer comment that arouse while testing a recent fix for network interface removal via Web-UI:
#2817 (comment)

And the following contextual issues/design directions:

• Ability to reset services to original status/settings Ability to reset services to original status/settings #2332
• Failure to start Shellinabox from System or breadcumbs links if unconfigured Failure to start Shellinabox from System or breadcumbs links if unconfigured #2773 where the following comment indicates a related inelegance (not not a silent failure) relating to default null config: Failure to start Shellinabox from System or breadcumbs links if unconfigured #2773 (comment)

[phillxnet]

It is proposed that, given the current default of null for the 'rockstor' service, and via the above detailed aims to have this as the service norm: that we accommodate appropriately and simple circumvent this check when there is no definition of a management interface yet available. A spin-off dedicated issue could be created to address the need to auto-establish a non-null config for the Web-UI/management interface but that is outside the scope of this issue. And given our stated context of approaching a system-wide null config capability: we should similarly not fail in the current manner indicated by the quoted log entry (post merge of #2817 which then clears the way for a reproducer here).

[phillxnet]

Closing as:
Fixed by #2822