fix(json-schema-2020-12-samples): Don't use maxint as default example value for int32 and int64

[hkosova]

Description

Swagger UI's example generator for OpenAPI 3.0 and 2.0 uses 0 as the default example value for integers with format: int32 and format: int62. But the example generator for OAS 3.1 uses 1073741824 and 9007199254740991 for some reason.

This change in example values can confuse people who migrate from OAS 3.0 to 3.1 - as reported in #9816. Also these huge values are unlikely to be encountered in real-life APIs.

This PR changes the default int32 and int64 examples used for OAS 3.1 back to 0 for consistency between OAS 3.1 and 3.0/2.0 example generators.

Note

If you prefer 1 (or 2 or another "small" number) as the default example value, let me know and I'll update the PR.

Motivation and Context

• Fixes When the openapi version is changed to 3.1.0 from 3.0.3, integer values are assigned the maximum value. #9816
• Makes OAS 3.1 example generator for integers consistent with 3.0/2.0.

How Has This Been Tested?

Tested manually + updated unit tests.

Screenshots (if appropriate):

Before:

After:

Test schema:

openapi: 3.1.0
...
components:
  schemas:
    MyObject:
      type: object
      properties:
        int32:
          type: integer
          format: int32
        int64:
          type: integer
          format: int64

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.