The goal here is to honor serializer options being passed into the serializers and deserializers when being called by a command, which are only loosely coupled with the state of the feature flags. There are 6 primary scenarios we need to consider:
- Command Request Serialization --> Route to 5
- Command Request Deserialization
- Command Reply Serialization
- Command Reply Deserialization --> Route to 6
- Storage/Default Serialization (adheres to feature flag)
- Storage/Default Deserialization (adheres to feature flag)
Non-command scenarios 5 and 6 will maintain the existing behavior dictated by feature flag states. As Scenario 1 maintains existing behavior since it is primarily used for server-to-server communication that is NOT dependent on Atlas Proxy, we should route it to Scenario 5. Scenario 2 and 3 are described separately in the two sections here, and any names returned in command responses should adhere to those rules when deciding whether to prefix or not. Scenario 4 is used primarily for deserializing requests from other servers (ie. complementary to Scenario 1), so it also abides by flag-defined behaviors (Scenario 6).