[API] Experiment with utoipa for API

[banool]

Description

This is an experiment using utoipa to generate our OpenAPI spec. This is what it spits out:

{

  "openapi": "3.0.3",
  "info": {
    "title": "aptos-api",
    "description": "Aptos REST API",
    "contact": {
      "name": "Aptos Labs",
      "email": "[email protected]"
    },
    "license": {
      "name": "Apache-2.0"
    },
    "version": "0.1.0"
  },
  "paths": {
    "/": {
      "get": {
        "tags": [
          "crate"
        ],
        "description": "",
        "operationId": "index",
        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/IndexResponse"
                }
              }
            }
          },
          "500": {
            "description": "Error"
          }
        },
        "deprecated": false
      }
    }
  },
  "components": {
    "schemas": {
      "IndexResponse": {
        "type": "object",
        "required": [
          "ledger_info",
          "node_role"
        ],
        "properties": {
          "node_role": {
            "$ref": "#/components/schemas/RoleType"
          },
          "ledger_info": {
            "$ref": "#/components/schemas/LedgerInfo"
          }
        },
        "description": "The struct holding all data returned to the client by the"
      },
      "U64": {
        "type": "integer",
        "format": "int64"
      },
      "LedgerInfo": {
        "type": "object",
        "required": [
          "chain_id",
          "epoch",
          "ledger_version",
          "oldest_ledger_version",
          "ledger_timestamp"
        ],
        "properties": {
          "ledger_version": {
            "$ref": "#/components/schemas/U64"
          },
          "oldest_ledger_version": {
            "$ref": "#/components/schemas/U64"
          },
          "ledger_timestamp": {
            "$ref": "#/components/schemas/U64"
          },
          "chain_id": {
            "type": "integer",
            "format": "int32"
          },
          "epoch": {
            "type": "integer",
            "format": "int64"
          }
        }
      },
      "RoleType": {
        "type": "string",
        "enum": [
          "validator",
          "full_node"
        ]
      }
    }
  }
}

Off the bat there are few issues compared to Poem (#1906):

• The description gets cut off.
• It allows you to not specify components that comprise higher level components. Originally I specified IndexResponse but not LedgerInfo and RoleType, and it happily generates the spec: https://gist.github.com/banool/839bb49c3c019de4c87c4c4c5e5fc275. I consider this an easy road to potential errors.
• There is no way to flatten structs right now: #[serde(flatten)] may not be supported (yet) juhaku/utoipa#120
• You have to specify your paths twice, once for the framework, once for utoipa.
• You have to manually say what your path returns. Poem at least does the 200 path for you.

There is more experimentation I could do if we wanted to go with this route, I haven't looked into how it handles more complex paths, errors, etc.

The main win with utoipa is you can use whatever framework you want, but that results in you needing to do more work yourself, leading to more opportunities for mistakes.

Naturally this is not exactly how I'd actually integrate utoipa, this is just to demonstrate what it'd look like.

Test Plan

---

This change is 

[banool]

Abandoning this, utoipa isn't quite there yet.