autogenerate: treat empty string comments as no comment (#1085)

[IMGillusion]

Fixes #1085

Problem

Setting comment="" (empty string) on a column or table in the metadata
causes autogenerate to report a spurious change on every run, even
though nothing changed in the database:

• the empty string comment is sent to the database, which stores/strips
  it (an empty comment is just no comment), so reflection returns None
• the comparators in alembic/autogenerate/compare/comments.py compare
  the reflected None against the metadata "" with a plain !=,
  so None != "" fires a false positive
• _compare_column_comment emits a spurious modify_comment=""
  (alter column) and _compare_table_comment emits a spurious
  CreateTableCommentOp/DropTableCommentOp

This makes sequential autogenerate runs non-idempotent for any model
that uses an empty string comment.

Fix

Normalize "" to None for both sides before comparing in
_compare_column_comment and _compare_table_comment. An empty comment
and no comment are semantically identical (the database cannot
distinguish them), so no diff is reported. Real comment changes
(add/remove/modify a non-empty comment) are unaffected.

Verification

• New regression tests CommentEmptyStringNoFalsePositiveTest
  (4 tests) in tests/test_autogen_diffs.py exercise the comparators
  directly with a comment-supporting dialect stub, so they run on any
  backend (including sqlite, whose dialect reports
  supports_comments=False and would otherwise short-circuit the
  comparator in an end-to-end run)
• Red: on the pristine code, the two *_empty_string_vs_none tests fail
  (comparator returns STOP where CONTINUE is expected)
• Green: with the fix, all 4 tests pass
• Full sqlite suite: 1856 passed / 134 skipped, zero new failures
  (8 pre-existing environment failures in test_post_write.py fail
  identically on pristine main)

[sqla-tester]

Hi, and thanks for the pull request!

This project accepts pull requests only for issues that a maintainer has already marked with the open for pull requests label. That way we can settle on an approach before anyone spends time writing code.

This pull request references issue #1085, which hasn't been marked open for pull requests, so the change isn't authorized yet and I'm closing it automatically. Once a maintainer adds the label to #1085, reopen this pull request and it will stay open. If #1085 needs more detail before that can happen, a complete runnable example is usually the missing piece, and adding one to the issue is the fastest way to get there.

This is automatic and procedural. It isn't a judgment on your change, and nothing you've written here is lost.

Thanks for your interest in the project!