details is an ambigue parameter name

the parameter name 'details' can mean different things in different API calls. These should be aligned and/or renamed. see the discussion in #3331

##### ISSUE TYPE
* Improvement Request

##### COMPONENT NAME

~~~
API
~~~

##### CLOUDSTACK VERSION

~~~
all
~~~

##### SUMMARY

| type of details field | class |
| - | - |
| | Commands: |
| Map | RegisterOAuthProviderCmd.java |
Map | BaseUpdateTemplateOrIsoCmd.java
List\ | ListHostsCmd.java
Map | UpdateZoneCmd.java
Map | CreateNetworkOfferingCmd.java
Map | UpdateBgpPeerCmd.java
Map | CreateBgpPeerCmd.java
Map | UpgradeSystemVMCmd.java
Map | ScaleSystemVMCmd.java
Map | UpdateStoragePoolCmd.java
Map | UpdateCloudToUseObjectStoreCmd.java
Map | AddImageStoreCmd.java
Map> | CreateSecondaryStagingStoreCmd.java
Map | AddObjectStoragePoolCmd.java
Map | CreateStoragePoolCmd.java
Map | ImportUnmanagedInstanceCmd.java
Map | AddGuestOsCmd.java
Map | UpdateGuestOsCmd.java
Map | CreateDiskOfferingCmd.java
| List\ | ListDomainsCmd.java
Map | CreateTemplateCmd.java
Map | GetUploadParamsForTemplateCmd.java
Map | RegisterTemplateCmd.java
List\ | ListTemplatesCmd.java
List\ | ListProjectsCmd.java
Map | UpgradeVMCmd.java
List\ | ListVMsCmd.java
Map | DeployVMCmd.java
Map | UpdateVMCmd.java
Map | RestoreVMCmd.java
| Map | ScaleVMCmd.java |
| List\ | ListAccountsCmd.java |
| Map | AddResourceDetailCmd.java |
| | Responses: |
| Map | TemplateResponse.java |
Map | NetworkOfferingResponse.java
Map | VolumeForImportResponse.java
String | DirectDownloadCertificateHostStatusResponse.java
Map | NetworkProtocolResponse.java
Map | UserVmResponse.java
Map | BgpPeerResponse.java
Map | DiskOfferingResponse.java
Map | NetworkResponse.java
String | CreateConsoleEndpointResponse.java
String | RouterHealthCheckResultResponse.java
Map> | DetailOptionsResponse.java
Map | HostResponse.java
String | UnmanageVMInstanceResponse.java

In addtion to these there are some details related parameters that also have different types i.e. details and some of them even as boolean.

There are two improvements to make here:
1. make sure there are no ambiguities for users when they encounter a in- or output field named “details”
2. make sure maintainers do not mix different patterns for the same basic functionality
the first being the more important one

In addition to all this there are backwards compatibility concerns. Some can be changed “under the hood” others will have to be marked as “deprecated" to the user and and copied into a in-/output field with a new name, only considering the old one if the new one is missing.

##### EXPECTED RESULTS
A clear pattern from both user and developer point of view.

Bắt đầu với phần thảo luận trong #3331 và danh mục trong issue này, sau đó so sánh các lớp API tiêu biểu như RegisterOAuthProviderCmd.java, ListHostsCmd.java và TemplateResponse.java. Ánh xạ các trường details khác nhau và xác định các ràng buộc về khả năng tương thích ngược. Công việc được xem là hoàn tất khi có một quy ước đặt tên nhất quán đã được người dùng và maintainer thống nhất, đồng thời xác định các trường deprecated trong những trường hợp không thể đổi tên một cách trong suốt.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.