Introduce SqlFieldType Abstraction and Enhance MySQL Result Handling;

[karthikeyan-netizen]

Summary

This pull request introduces a new SqlFieldType enumeration and enhances MySQL result handling to provide explicit SQL field type representation, improved type safety, and thread-safe metadata access.

The goal is to provide a structured SQL field type abstraction for MySQL while preserving backward compatibility.

---

Motivation

Currently, Drogon does not provide a unified abstraction for SQL field types in MySQL result handling. This PR addresses that gap by introducing:

• A new SqlFieldType enumeration to represent SQL-native data types
• Internal MySQL-to-SqlFieldType mapping logic
• Helper methods for safer and clearer type interpretation when accessing result fields
• Thread-safe field metadata access with bounds checking

This enables stronger type awareness and prepares the foundation for future database-related enhancements.

---

Changes Introduced

1. SqlFieldType Enumeration

• Added SqlFieldType enum with complete MySQL FIELD_TYPE_* mappings
• Integrated into MySQL result processing (MysqlResultImpl, ResultImpl, Result, Field)
• Type-safe field interpretation across the ORM layer

2. MySQL Result Enhancements

• Extended MysqlResultImpl to expose and utilize SqlFieldType
• Added helper methods for improved field access and type interpretation
• Updated Result and ResultImpl to support the new abstraction

3. Safety & Code Quality Improvements

• Thread-safe metadata access: ColumnMeta struct designed with immutable (const) members to prevent accidental mutation
• Bounds checking: Implemented bounds validation to prevent undefined behavior on invalid column access
• Code consolidation: Merged duplicate field-processing loops in constructor to reduce redundancy
• Complete API documentation: All new public methods include comprehensive Doxygen comments with parameter ranges, return values, and MySQL-specific caveats

4. Related Adjustments

• Updated affected components (field.*, Result.*, and related implementations) to maintain consistent integration
• PostgreSQL and SQLite implementations remain unaffected

---

Compatibility

• ✅ No breaking changes to existing public APIs
• ✅ Existing behavior remains unchanged unless new functionality is explicitly used
• ✅ SqlFieldType abstraction is fully additive
• ✅ Backward compatible with all existing result handling code

---

Production Validation

• Tested in production-like environment for approximately one month
• No regressions or performance issues observed
• Type mapping validated across common MySQL field types

---

Notes

I welcome feedback regarding:

• The design and scope of the SqlFieldType abstraction
• API surface considerations
• Alternative approaches if preferred by maintainers

[an-tao]

Since this PR introduces a new public type abstraction, could we add a metadata test covering the MySQL field types?

At minimum, I think the test should cover:

TINYINT
SMALLINT
MEDIUMINT
INT
BIGINT
FLOAT
DOUBLE
DECIMAL(M,D)
CHAR/VARCHAR
TEXT/TINYTEXT/MEDIUMTEXT/LONGTEXT
BLOB/TINYBLOB/MEDIUMBLOB/LONGBLOB
BINARY/VARBINARY
DATE/TIME/DATETIME
BIT
JSON
YEAR

This would also make it much harder to accidentally regress the mapping when new database metadata support is added.