[dev-1.1.2](memory) Default STRICT_MEMORY_USE reduce hash table memory

[xinyiZzz]

Proposed changes

Issue Number: close #xxx

Problem summary

1. ssb3.1 vectorization uses twice as much memory as non-vectorization

ssb	vec true	vec false
2.1	352M	185M
3.1	1303M	470M
4.1	2181M	748M

2. Vectorized query ssb 3.1 memory analysis

the memory is mainly composed of 4 parts

1. The memory ratio of each part in the first run query: scanner_thread (57%), hash_table_build_thread (32%), open + get_next (8.6%), prepare (5.4%)

2. The memory ratio of each part in the second run query, he page cache has been cached: scanner_thread (12%), hash_table_build_thread (61.9%), open + get_next (15.3%), prepare (10.8%)

3. Change the hash table to 75% fill, which can reduce memory usage by 30%.

	Growing physical memory peak	query mem tracker peak	scanner_thread tracker peak	_hash_table_build_thread tracker peak	_exec_actual tracker peak	PlanFragmentExecutor::prepare tracker peak
first run	10702M	2406M	1368M	770M	207M	132M
second run	1291M	1218M(少70?)	147M	754M	187M	132M
75% max_fillfirst run	10721M	2046M	1364M	406M	207M	132M
75% max_fillsecond run	924M	856M(少70?)	141M	405M	190M	132M

3. Non-vectorized query ssb 3.1 memory analysis

The memory size of the non-vectorized hash table is 34% of that of the vectorized hash table.

	Growing physical memory peak	query mem tracker peak	scanner_thread tracker peak	_hash_table_build_thread tracker peak	_exec_actual tracker peak	PlanFragmentExecutor::prepare tracker peak
first run	11311M	2554M	1904M	265M	749M	135M
second run	1050M	1344M	626M	272M

Checklist(Required)

1. Does it affect the original behavior:
   • Yes
   • No
   • I don't know
2. Has unit tests been added:
   • Yes
   • No
   • No Need
3. Has document been added or modified:
   • Yes
   • No
   • No Need
4. Does it need to update dependencies:
   • Yes
   • No
5. Are there any changes that cannot be rolled back:
   • Yes (If Yes, please explain WHY)
   • No

Further comments

If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

[yiguolei]

LGTM