GH-51779: [C++][IPC] Read a DictionaryEncoding without indexType as int32 indices

[CaptainAni187]

Rationale for this change

Schema.fbs allows DictionaryEncoding.indexType to be omitted: "If this field is null, the indices must be signed int32." The C++ IPC reader required it instead, so C++ and PyArrow failed to read such a stream with IOError: Unexpected null field DictionaryEncoding.indexType in flatbuffer-encoded metadata.

What changes are included in this PR?

FieldFromFlatbuffer uses int32() as the index type when indexType is absent, instead of failing the null check.

Are these changes tested?

Yes. TestMessageInternal.DictionaryEncodingWithoutIndexType builds a schema message whose dictionary-encoded field has no indexType and checks that ReadSchema returns dictionary<values=string, indices=int32>. On main it fails with the error above. The arrow-ipc-* tests pass locally.

Are there any user-facing changes?

Streams that omit indexType can now be read. Streams that include it are read as before.

Was AI used for this PR?

In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

• GitHub Issue: [C++][Python] IPC reader rejects a DictionaryEncoding without indexType, which the format allows #51779

[github-actions]

⚠️ GitHub issue #51779 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #51779 has been automatically assigned in GitHub to PR creator.

[ianmcook]

The test copies the flatbuffer into a Buffer by hand through a std::string. internal::WriteFlatbufferBuilder(fbb) already does this (read_write_test.cc uses it) and would also make the new #include <string> unnecessary.

[CaptainAni187]

Done in 7453d8a, and the <string> include is gone.

[ianmcook]

Could we also check that the field was registered in memo? The schema comparison passes even if the new code path never registers the field. A reader needs that registration to match the field to the DictionaryBatch and RecordBatch that follow, and that's where #51779 failed. Something like:

  ASSERT_OK_AND_EQ(0, memo.fields().GetFieldId({0}));
  ASSERT_OK_AND_ASSIGN(auto dict_value_type, memo.GetDictionaryType(0));
  AssertTypeEqual(utf8(), dict_value_type);

[CaptainAni187]

Added in 7453d8a: the test now checks the field ID and that the dictionary value type is utf8().