chore: update shared schema spec for consistency

[mkurapov]

There is an open Rafiki PR that generates Typescript types from the Open API spec using the openapi-typescript package.
Whenever type generation script runs, it generates a file with types as such:

export interface paths {
   ...
}

export interface components {
   schemas: {
      ...
   }
   responses: {
      ...
   }
   parameters: {
      ...
   }
}

export interface operations {
   ...
}

export interface external {
   ...
}

The external interface is the one that holds references to the types for when an external $ref is used in a spec (e.g. $ref: ../shared/schemas.yaml#/amount.

However, after the spec split, the type generation for the resource server failed to populate this external interface, since shared/schemas.yaml was declaring components directly at the root like:

assetCode:
  title: Asset code
  type: string
  description: The assetCode is a code that indicates the underlying asset. This SHOULD be an ISO4217 currency code.

The generator can only populate the external/shared schema interface if using the components -> schemas declaration, meaning the shared schema items must be declared like:

components:
  schema:
    ...
    assetCode:
      title: Asset code
      type: string
      description: The assetCode is a code that indicates the underlying asset. This SHOULD be an ISO4217 currency code.

This PR nests the fields in openapi/shared/schemas.yaml to be under components -> schemas in order to allow type generation to work. If this is too much of a change to support this tool, I might be able to figure out a different (possibly convoluted) solution, but I thought this standardization wouldn't cause issues nor be too much of a stretch.

[mkurapov]

not necessary perse, but just additional information

[mkurapov]

no changes other than this nesting

[wilsonianb]

related issue:

• Feature request: support for external files in $ref openapi-ts/openapi-typescript#892

We can consider reverting this if/when that's resolved.

[mkurapov]

@wilsonianb yes, that's the one I was looking at, the final response in that issue was a bit different than the earlier one in that thread that was relevant to this change. I hope if there is a change to the library both of those fixes will be addressed.