Deprecation of composite key functionality

[darbio]

This is an issue to get feedback from the community on the removal of the composite keys functionality in favour of always using default.

@jeremydaly has mentioned in a number of issues that this is something that he is interested in doing to make the library have less feature bloat, adhere to current best practices and hence less "buggy".

I agree with this for the following reasons:

1. Current best practices recommend splitting your data access attributes (pk, sk, gsi_pk etc.) from your application attributes (id, username, name etc.).
2. There are a plethora of issues created by people using composite keys which are solved using default.
3. Composite keys are very prominent in the README and are the first port of call for people coming to this library.

I'd be interested to hear others opinions on this - I understand that this may be a major breaking change for some people, with the upgrade route being to migrate to default.

[jeremydaly]

+100000000000000 😉

[vsnig]

+1 Never used them, always been using default. Default => template literal is declarative and straight forward.

[fargito]

I completely agree with this !

[whtlnv]

I've been immersing myself in this library just recently and can attest that the default behavior of composite keys:

1. Is not compatible with Alex DeBrie's recommendations, which as of now is one of the few formal documentations on single-table design.
2. Is not extensible to several indexes using the same attribute, which is not an uncommon use case
3. Replicates existing functionality without being exactly a short hand.
4. Makes it harder to understand the construction of the index, that's to say, the index definition doesn't contain information of the parameters required to build it.
5. Not sure if this is a bug, but the map option on a composite key is not working.
6. (100% opinion) Its syntax is so different to the standard attribute definition that it introduces friction while adopting the library.

If I may put forward my humble opinion, the feature could be kept for backwards compatibility, but every reference to its use be removed from the documentation and only mentioned in a "Legacy" section.