What problem does this PR solve?

Issue Number: close #5859

Problem Summary:
TiFlash assumes all values in the column with "primary key" flag are non-null value.

However, users could create such "NULL" value in the "primary key" column by following steps

-- create table with `source` is nullable
create table test.t_case (
`case_no` varchar(32) not null,
`source` varchar(20) default null,
`p` varchar(12) DEFAULT NULL,
primary key (`case_no`)
);

-- insert some data and left `source` to be empty
insert into test.t_case(case_no)
values ("1"), ("2"), ("3"), ("4");

-- drop the primary key, fill the `source` to be non-empty
alter table t_case drop primary key;
update test.t_case set `source` = '' where `source` is NULL;
-- add new primary key with case_no and source
alter table t_case add primary key (case_no, source);

-- send the snapshot data to tiflash
alter table t_case set tiflash replica 1;

What is changed and how it works?

• mainly change the logic in addDefaultValueToColumnIfPossible
  • For non-clustered index table(is_common_handle=false && pk_is_handle=false), fill default value even if the column contains primary key flag when the column is not appear in the encoded value(those rows are not supposed to be return to users)
  • For clustered index/pk_is_handle table, ignore the primary key column as they are supposed to be decoded from the encoded key
• Refine the exception message in insertRangeFrom
• Add more region info when exception thrown in preHandleSnapshot/ingestSST

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Fix the panic issue after creating the primary index with a column containing `NULL` value