In relation to: #15162, #15610, #15611

This PR aims to fix the operation servers functionality. As of v6.6.0, if the user of the SDK does not define server_operation_index to map each operation to a server index, the default base url for the api will be used. This reverted the behavior prior to 6.6.0, which defaulted to using an operation specific server if one was defined, without needing to specify the index of the server to use. Prior to 6.6.0, the case constructing the base url using scheme, host, and base_path was unreachable unless the user specified to use nil as the index, as explained by @Confusion in #15162.

This PR assumes the following:

1. If servers are defined for a specific operation, by default, they should be given priority over the default base url (top level servers) for the spec.
2. The first server in any servers array should be the default server to use.
3. If the user changes the server index to use, either by updating server_index or the server_operation_index hash, that index should be used and the proper variables have been defined for the url at that index.

Based on these assumptions, the SDK will now:

• Use operation servers if they are defined, using the index defined in server_operation_index if one is defined for that operation, or defaulting to server_index (or 0 if server_index is nil) for which server to use.
• Refer to the server_settings hash if no operation server is defined and the user has defined a server_index.
• Return the default base url built using scheme, host, and base_path if there is no operation server defined and the server_index is nil (the new default value)

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.
• In case you are adding a new generator, run the following additional script :

  ./bin/utils/ensure-up-to-date
  

  Commit all changed files.
• File the PR against the correct branch: master (6.3.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@cliffano (2017/07) @zlx (2017/09) @autopp (2019/02)