Request Body content-types don't consider custom parameters

[rayvincent2]

Describe the bug
There are a few issues that come from not having the request body content types resolved by their equivalents instead of by sorting the params and normalizing the content-type before comparing against the available openapi content types.

To Reproduce/Actual behavior/Examples and context
Considering this openapi document:

...
paths:
  /pets_content_types:
    post:
      description: Creates a new pet in the store.  Duplicates are allowed
      requestBody:
        description: Pet to add to the store
        required: true
        content:
          application/json; version=1:
            schema:
              $ref: '#/components/schemas/NewPet'
      responses:
        '200':
          description: pet response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Pet'
        default:
          description: unexpected error
          content:
            application/json; charset=utf-8:
              schema:
                $ref: '#/components/schemas/Error'

If the first request has application/json; version=1 for the request body's content type, then openapi-validator will generate a cached validator which includes the content type used. The problem is that the cache key doesn't include the request-body params.

POST /pets_content_types HTTP/1.1
Content-Type: application/json; version=1
Accept: application/json

{
  "name": "curly",
  "tag": "bald"
}

This request would result in a validator cached as GET-/pets_content_types-application/json. Subsequent requests with unsupported versions now use the same key and may return 200 instead of 415 because the requestBody content-type is in-fact not supported.

Expected behavior
Every request with a different requestBody content-type should be analyzed separately. If the cache is used, then the content types must be normalized to ensure that any parameters provided in different orders create the same cache key.

All of these should also result in different cache keys so each have a chance to return a 415 status code. Currently, they all result in the same cache key.

• application/json; version=1
• application/json; param1=1
• application/json

Likewise, both of these content-types should result in the same cache key

• application/json; version=1; charset=utf-8; param1=1
• application/json; param1=1; charset=utf-8; version=1