Revisit default constants in `RequestOptions`, `Context`, `BinaryData` and similar classes
We currently use things like RequestOptions.NONE or Context.EMTPY to avoid creating "empty" default instances in objects that might not need them and get created and discarded often. We've also previously discussed using methods like Context.emtpy() instead.
Let's take a look at the whole library and see if there are cases where we need to take one approach or the other, document them well and be more consistent.
Let's record the final naming decision here:
/**
* An empty BinaryData that is immutable, used in situations where there is no binary data, but a BinaryData instance is expected.
*/
BinaryData.empty()
/**
* An empty RequestOptions that is immutable, used in situations where there is no request-specific configuration to pass into the request. Modifications to the RequestOptions will result in a <insert appropriate exception type here>
*/
RequestOptions.none()
/**
* An empty Context that is immutable, used in situations where there is no context-specific content to pass into the request. Modifications to the Context will result in a <insert appropriate exception type here>
*/
Context.none()
We should also look into what we should do for Configuration.PROPERTY_* constants.
https://github.com/Azure/azure-sdk-for-java/blob/feature/generic-sdk-core-2/sdk/client-core/core/src/main/java/io/clientcore/core/util/configuration/Configuration.java#L40-L94