SDX delete connection should accept both integer and connection GUID

[congwang09]

We can make SDX controller accept both integer or connection GUID for connection deletion API.

[sajith]

@congwang09 What would be the rationale for this?

I've been looking at this a bit in #225. If I understand correctly, the way to implement in the OpenAPI definition would entail a change like this in the API definition:

diff --git a/sdx_controller/swagger/swagger.yaml b/sdx_controller/swagger/swagger.yaml
index 9018e61..49faf75 100644
--- a/sdx_controller/swagger/swagger.yaml
+++ b/sdx_controller/swagger/swagger.yaml
@@ -174,8 +174,11 @@ paths:
         schema:
           maximum: 10
           minimum: 1
-          type: integer
-          format: int64
+          anyOf:
+            - type: string
+              format: uuid
+            - type: integer
+              format: int64
       responses:
         "200":
           description: successful operation
@@ -206,8 +209,11 @@ paths:
         explode: false
         schema:
           minimum: 1
-          type: string
-          format: uuid
+          oneOf:
+            - type: string
+              format: uuid
+            - type: integer
+              format: int64
       responses:
         "400":
           description: Invalid ID supplied

This passes muster by openapi-spec-validator, but connexion (at least connection 2.14.1 that we're using, which is rather old) can't handle this:

ERROR    sdx_controller:app.py:1744 Exception on /SDX-Controller/1.0.0/connection/9db07776-1f1a-4e5f-9112-1ebb4c08db5f [DELETE]
Traceback (most recent call last):
  File ".tox/py3/lib/python3.11/site-packages/flask/app.py", line 2529, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".tox/py3/lib/python3.11/site-packages/flask/app.py", line 1825, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".tox/py3/lib/python3.11/site-packages/flask/app.py", line 1823, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File ".tox/py3/lib/python3.11/site-packages/flask/app.py", line 1799, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".tox/py3/lib/python3.11/site-packages/connexion/decorators/decorator.py", line 68, in wrapper
    response = function(request)
               ^^^^^^^^^^^^^^^^^
  File ".tox/py3/lib/python3.11/site-packages/connexion/decorators/uri_parsing.py", line 147, in wrapper
    request.path_params = self.resolve_path(path_params)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".tox/py3/lib/python3.11/site-packages/connexion/decorators/uri_parsing.py", line 240, in resolve_path
    return self.resolve_params(path_data, 'path')
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".tox/py3/lib/python3.11/site-packages/connexion/decorators/uri_parsing.py", line 116, in resolve_params
    if param_schema and param_schema['type'] == 'array':
                        ~~~~~~~~~~~~^^^^^^^^
KeyError: 'type'

I think I will simply switch to UUIDs as connection IDs in #225, and then if we must have both integers and UUIDs, we can handle that separately.