[Feature] Handle optional operation responses

Created by: Paul-Etienne

I've come across a problem implementing an API for Swift5 with an operation that could both answer a 200 response with a result body and an empty 202 response, so without any response body.

The problem concerns the Swift language, and most likely any other language that gracefully handles nulls, like Kotlin. When generating the API for such an operation, the result, while using RxSwift, is an Observable<ResponseObject> and not an Observable<ResponseObject?> (note the ? that specifies that the response object can be null). This and the fact that the implementation of the class URLSessionImplementations line 355-358 forces a failure in case an operation with a response returns an empty body, prevents this operation from ever returning a successful 202 response with no response body.

I've worked to overcome this issue, but to do so I needed a new variable that would indicate if an operation's response is optional, meaning that an operation can both return a 2xx response with a body and a 2xx response with no body. I've added this variable in my first commit, and then used it in my second commit to edit the Swift5 template and generate an Observable<ResponseObject?> whenever a response is optional. I've also edited the URLSessionImplementations class to allow an empty response body whenever the generic type is an optional (which means the operation has an optional response).

I've only implemented the case of Swift5 using RxSwift so far 'cause it's our use case, but there's no reason not to extend this feature to more libraries and languages if you guys think this can be useful to someone. I can't really test it out with other libraries or languages right now though, so feel free to add to this conversation if you feel like building onto this.

Sorry if I didn't open an issue first, feel free to discuss this feature suggestion here directly.

Edit: I should probably edit sample APIs to highlight the changes for operations that fall in the scope of this feature.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh

  Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Swift5 technical committee : @jgavris (2017/07) @ehyche (2017/08) @Edubits (2017/09) @jaz-ah (2017/09) @4brunu (2019/11)