[FLINK-39283][Formats/avro] Upgrade org.apache.avro:avro to 1.12.1

[snuyanzin]

What is the purpose of the change

as mentioned source (https://avro.apache.org/blog/2025/10/16/avro-1.12.1/)

Security Fixes

This release addresses 4 security fixes:

Prevent class with empty Java package being trusted by SpecificDatumReader (#3311)
Remove the default serializable packages and deprecated the property to introduce org.apache.avro.SERIALIZABLE_CLASSES instead (#3376)
java-[key-]class allowed packages must be packages (#3453)
AVRO-4053: doc consistency in velocity templates (#3150)

Brief change log

pom and NOTICE files

Verifying this change

existing tests

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes )
• The public API, i.e., is any changed class annotated with @Public(Evolving): ( no)
• The serializers: (no)
• The runtime per-record code paths (performance sensitive): (no )
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no )
• The S3 file system connector: (no)

Documentation

• Does this pull request introduce a new feature? ( no)
• If yes, how is the feature documented? (not applicable)

[flinkbot]

CI report:

• 2e381f1 Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[mukul-8]

One thing to consider with this upgrade — Avro 1.12.1 enables fastReaderEnabled=true by default in GenericDatumReader/
SpecificDatumReader. This introduces an optimized execution plan for deserialization that gets rebuilt whenever
setSchema() is called.

In Flink, AvroDeserializationSchema.deserialize() calls datumReader.setSchema(readerSchema) on every record. With the
fast reader enabled, this means the optimized execution plan is rebuilt per record, which could negate the performance
benefit and potentially cause a regression compared to 1.11.x.

This is discussed in detail in #27499 (FLINK-39005). It would be worth studying the impact before merging — either benchmarking the current setSchema-per-record path with fastReaderEnabled=true, or explicitly setting fastReaderEnabled=false until the redundant setSchema() call is addressed.