Implement and enforce requirements for entity type names

[davemoore-]

Currently entity type names can be any arbitrary string. As noted in another discussion, this is problematic when implementing API endpoints that could conflict with the names of entity types. There may be other unforeseen issues by using arbitrary strings. Entity type names are meant to be identifiers, not necessarily human readable descriptions, and therefore should be expected to follow some constraints.

Proposal

Enforce the same requirements as the Elasticsearch index name requirements:

Index names must meet the following criteria:

• Lowercase only
• Cannot include \, /, *, ?, ", <, >, |, (space character), ,, #
• Indices prior to 7.0 could contain a colon (:), but that’s been deprecated and won’t be supported in 7.0+
• Cannot start with -, _, +
• Cannot be . or ..
• Cannot be longer than 255 bytes (note it is bytes, so multi-byte characters will count towards the 255 limit faster)
• Names starting with . are deprecated, except for hidden indices and internal indices managed by plugins

Entity type names should follow the same rules (though allowing names to start with .). This will prevent entity type names from conflicting with reserved API terms such as _bulk and may help avoid other unforeseen issues related to syntax.

This would introduce a breaking change for existing entity models whose names do not meet this criteria.

[austince]

If you're not already working on this, I think I can submit a PR to cover it today.

[davemoore-]

@austince Sure that'd be great. I'll be focusing my near-term efforts on the hanging requests issue.

On that note, I started a discussion on a collaborative branching strategy, which I haven't had to think about as the sole contributor to the project. Your feedback will be helpful here.