Summary

BsonNamingStrategy being enum, limited to only SNAKE_CASE and having a bunch of hardcode `when/if` blocks across the code makes it's implementation messy and bad for future extension. I would like to propose to make BsonNamingStrategy an interface, with all included functionality, needed in `when/if` blocks in codebase. This will allow extending implementation with custom naming strategies. 

Motivation

Who is the affected end user?

Any developer using `bson-kotlinx`

How does this affect the end user?

With hardcoded SNAKE_CASE developer has no control over field naming. If developer wants other then SNAKE_CASE naming he will need to fork mongodb java driver.

How likely is it that this problem or use case will occur?

Likely, when developer likes other naming strategy in database, or want custom name remapping (id -> _id)

If the problem does occur, what are the consequences and how severe are they?

I have Kotlin Backend project with a bunch of entities. I want to persist them in mongodb and also return on API, but because of mongodb hardcoded naming I forced to annotate id field with @SerialName("_id"), which will affect API. With custom BsonNamingStrategy i can map "id" to "_id" safely, without affecting whole app. Also I don't like snake case in my db at all, minor inconvience.

Is this issue urgent?

No

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

No