(Display) Number Generation

[rjhllr]

This idea stems from an ongoing discussion with @olivermrbl and @adrien2p talking about the same concept for authentication systems (middlewares)
Most advanced ecom systems have some kind of a "number ranges" feature. This is often used in big companies where customers registering from the webshop get different customer numbers than e.g. internal customers. This is also often an requirement with migrations of existing shops: when importing the old orders, you often need some way to differ new incoming shop orders (prefix/suffix, different scheme…). Third example: numbers are generated by external systems (e.g. customer numbers for first-time webshop customers come from a CRM system, order numbers coming from ERP). Fourth example would be small/new stores (for obvious reasons) using random or massive-scale stores (for avoiding collisions) using UUIDs.

I've taken a look at orders out of interest. Currently, the display_id is implicitly generated by not being set in the orderService and then letting the DBMS handle the generation (as I understood it, see resolveDbGenerationStrategy, medusa/src/models/order.ts). Inserting a strategy that keeps the current behavior (= don't set a value, no-op strategy) would allow developers to very easily modify entity number generation.

Core change to achieve this for example for orders: 1 line in the orderService, one interface (/abstract class as per @adrien2p) added. Pretty neat.