fix: issue where custom assets are not injected in html

[joshunrau]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Options passed to SwaggerModule.setup are ignored. The customOptions object passed to buildSwaggerHTML is malformatted. Custom parameters that should be contained within the base of customOptions are actually contained within swaggerOptions, which itself contains another object swaggerOptions. For example, this is the object passed to buildSwaggerHTML when you run npm run start:dev:

{
  jsonDocumentUrl: '/api-docs-json',
  yamlDocumentUrl: '/api-docs-yaml',
  swaggerOptions: {
    customSiteTitle: 'Demo API - Swagger UI 1',
    swaggerOptions: {
      persistAuthorization: true,
      defaultModelsExpandDepth: -1,
      syntaxHighlight: [Object],
      tryItOutEnabled: true
    },
    customfavIcon: '/public/favicon.ico',
    customCssUrl: '/public/theme.css'
  }
}

I changed how the options are parsed from the customOptions object in buildSwaggerHTML.

Issue Number: #2481

What is the new behavior?

I implemented a quick fix to resolve the bug. Now, extracted the options from a merger of customOptions and customOptions.swaggerOptions. This is not an ideal solution, but it seems this object structure is assumed in several other places in the code base, and applying a more systematic fix was non-trivial, as someone who is unfamiliar with the project.

Does this PR introduce a breaking change?

• Yes
• No

Other information

I added tests for all of the custom assets so this will not inadvertently break again in the future.

[kamilmysliwiec]

Thanks for your contribution! I took a slightly different approach as it seems that the regression was introduced in this PR #2392 where we pass the outer options object instead of the Swagger-specific custom options object down to the function you modified. Still, I'm gonna merge this PR as it adds some valuable e2e tests and will prevent us from introducing similar breaking changes in the future!