Why:
I tried to solve the issue I found earlier, but found myself stuck in a quagmire
because the issues kept coming up while I fix the old one, so I finally decided
to rewrite it.

Issues with the old one:
- A node which should be compressed stays raw
  This is due to by poor design of quicklist->recompress, the design forgot the
  situation that a node could stay uncompressed if it can not compress small
  enough. And if we changed the node, wo should perform compress on it again.
  See issue redis#12563.
- Iterator don't behave like iterator
  Iterator will be reset and not avaliable for further use after replace or
  insert, see marcro resetIterator(). The only operation that athe iterator does
  not get reset is quicklistDelEntry(), and it has a commment about it, but the
  comment is wrong, the iterator may not behave like the comment says.
  See issue redis#12614.
- Packed node violate size limit
  Certen call to function quicklistReplaceEntry(), quicklistInsertBefore() and
  quicklistInsertAfter() will cause a packed node violate size limit.
  See issue redis#12548.
- Merge operation only performed in insert
  There is no merging in delete nor replace, which can make the quicklist
  contain adjacent small nodes.
  See issue redis#12856.
- Algorithms that maintain compress depth are not efficient
  the algorithm to maintain compress depth after add or delete is to check nodes
  on both sides of the list, time complexity is O(n), where n is the uncompressed
  depth on both sides of the list.

All the changes:
- Partition the node
  Divide the node into three partitions: head, middle and tail. The head and
  tail partitions hold uncompressed nodes, and the middle partition holds
  compressed nodes. Therefore,the time complexity of maintaining compress depth
  after adding or deleting a node will drop to O(1), moving at most one node
  from one partition to another.
- Removed annoying members recompress, attempted_compress and dont_compress from
  quicklist node structure
- Merge structure quicklistIter and quicklistEntry
- The historical parameter packed_threshold has been removed
  This is mentioned by @sundb and @oranagra in pull request redis#12568.
- Merge strategy is added
  That is that any adjacent node in quicklist can not be merged.

Why:
I tried to solve the issue I found earlier, but found myself stuck in a quagmire
because the issues kept coming up while I fix the old one, so I finally decided
to rewrite it.

Issues with the old one:
- A node which should be compressed stays raw
  This is due to by poor design of quicklist->recompress, the design forgot the
  situation that a node could stay uncompressed if it can not compress small
  enough. And if we changed the node, wo should perform compress on it again.
  See issue redis#12563.
- Iterator don't behave like iterator
  Iterator will be reset and not avaliable for further use after replace or
  insert, see marcro resetIterator(). The only operation that athe iterator does
  not get reset is quicklistDelEntry(), and it has a commment about it, but the
  comment is wrong, the iterator may not behave like the comment says.
  See issue redis#12614.
- Packed node violate size limit
  Certen call to function quicklistReplaceEntry(), quicklistInsertBefore() and
  quicklistInsertAfter() will cause a packed node violate size limit.
  See issue redis#12548.
- Merge operation only performed in insert
  There is no merging in delete nor replace, which can make the quicklist
  contain adjacent small nodes.
  See issue redis#12856.
- Algorithms that maintain compress depth are not efficient
  the algorithm to maintain compress depth after add or delete is to check nodes
  on both sides of the list, time complexity is O(n), where n is the uncompressed
  depth on both sides of the list.

All the changes:
- Partition the node
  Divide the node into three partitions: head, middle and tail. The head and
  tail partitions hold uncompressed nodes, and the middle partition holds
  compressed nodes. Therefore,the time complexity of maintaining compress depth
  after adding or deleting a node will drop to O(1), moving at most one node
  from one partition to another.
- Removed annoying members recompress, attempted_compress and dont_compress from
  quicklist node structure
- Merge structure quicklistIter and quicklistEntry
- The historical parameter packed_threshold has been removed
  This is mentioned by @sundb and @oranagra in pull request redis#12568.
- Merge strategy is added
  That is that any adjacent node in quicklist can not be merged.

Why:
I tried to solve the issue I found earlier, but found myself stuck in a quagmire
because the issues kept coming up while I fix the old one, so I finally decided
to rewrite it.

Issues with the old one:
- A node which should be compressed stays raw
  This is due to by poor design of quicklist->recompress, the design forgot the
  situation that a node could stay uncompressed if it can not compress small
  enough. And if we changed the node, wo should perform compress on it again.
  See issue redis#12563.
- Iterator don't behave like iterator
  Iterator will be reset and not avaliable for further use after replace or
  insert, see marcro resetIterator(). The only operation that athe iterator does
  not get reset is quicklistDelEntry(), and it has a commment about it, but the
  comment is wrong, the iterator may not behave like the comment says.
  See issue redis#12614.
- Packed node violate size limit
  Certen call to function quicklistReplaceEntry(), quicklistInsertBefore() and
  quicklistInsertAfter() will cause a packed node violate size limit.
  See issue redis#12548.
- Merge operation only performed in insert
  There is no merging in delete nor replace, which can make the quicklist
  contain adjacent small nodes.
  See issue redis#12856.
- Algorithms that maintain compress depth are not efficient
  the algorithm to maintain compress depth after add or delete is to check nodes
  on both sides of the list, time complexity is O(n), where n is the uncompressed
  depth on both sides of the list.

All the changes:
- Partition the node
  Divide the node into three partitions: head, middle and tail. The head and
  tail partitions hold uncompressed nodes, and the middle partition holds
  compressed nodes. Therefore,the time complexity of maintaining compress depth
  after adding or deleting a node will drop to O(1), moving at most one node
  from one partition to another.
- Removed annoying members recompress, attempted_compress and dont_compress from
  quicklist node structure
- Merge structure quicklistIter and quicklistEntry
- The historical parameter packed_threshold has been removed
  This is mentioned by @sundb and @oranagra in pull request redis#12568.
- Merge strategy is added
  That is that any adjacent node in quicklist can not be merged.

Why:
I tried to solve the issue I found earlier, but found myself stuck in a quagmire
because the issues kept coming up while I fix the old one, so I finally decided
to rewrite it.

Issues with the old one:
- A node which should be compressed stays raw
  This is due to by poor design of quicklist->recompress, the design forgot the
  situation that a node could stay uncompressed if it can not compress small
  enough. And if we changed the node, wo should perform compress on it again.
  See issue redis#12563.
- Iterator don't behave like iterator
  Iterator will be reset and not avaliable for further use after replace or
  insert, see marcro resetIterator(). The only operation that athe iterator does
  not get reset is quicklistDelEntry(), and it has a commment about it, but the
  comment is wrong, the iterator may not behave like the comment says.
  See issue redis#12614.
- Packed node violate size limit
  Certen call to function quicklistReplaceEntry(), quicklistInsertBefore() and
  quicklistInsertAfter() will cause a packed node violate size limit.
  See issue redis#12548.
- Merge operation only performed in insert
  There is no merging in delete nor replace, which can make the quicklist
  contain adjacent small nodes.
  See issue redis#12856.
- Algorithms that maintain compress depth are not efficient
  the algorithm to maintain compress depth after add or delete is to check nodes
  on both sides of the list, time complexity is O(n), where n is the uncompressed
  depth on both sides of the list.

All the changes:
- Partition the node
  Divide the node into three partitions: head, middle and tail. The head and
  tail partitions hold uncompressed nodes, and the middle partition holds
  compressed nodes. Therefore,the time complexity of maintaining compress depth
  after adding or deleting a node will drop to O(1), moving at most one node
  from one partition to another.
- Removed annoying members recompress, attempted_compress and dont_compress from
  quicklist node structure
- Merge structure quicklistIter and quicklistEntry
- The historical parameter packed_threshold has been removed
  This is mentioned by @sundb and @oranagra in pull request redis#12568.
- Merge strategy is added
  That is that any adjacent node in quicklist can not be merged.

Why:
I tried to solve the issue I found earlier, but found myself stuck in a quagmire
because the issues kept coming up while I fix the old one, so I finally decided
to rewrite it.

Issues with the old one:
- A node which should be compressed stays raw
  This is due to by poor design of quicklist->recompress, the design forgot the
  situation that a node could stay uncompressed if it can not compress small
  enough. And if we changed the node, wo should perform compress on it again.
  See issue redis#12563.
- Iterator don't behave like iterator
  Iterator will be reset and not avaliable for further use after replace or
  insert, see marcro resetIterator(). The only operation that athe iterator does
  not get reset is quicklistDelEntry(), and it has a commment about it, but the
  comment is wrong, the iterator may not behave like the comment says.
  See issue redis#12614.
- Packed node violate size limit
  Certen call to function quicklistReplaceEntry(), quicklistInsertBefore() and
  quicklistInsertAfter() will cause a packed node violate size limit.
  See issue redis#12548.
- Merge operation only performed in insert
  There is no merging in delete nor replace, which can make the quicklist
  contain adjacent small nodes.
  See issue redis#12856.
- Algorithms that maintain compress depth are not efficient
  the algorithm to maintain compress depth after add or delete is to check nodes
  on both sides of the list, time complexity is O(n), where n is the uncompressed
  depth on both sides of the list.

All the changes:
- Partition the node
  Divide the node into three partitions: head, middle and tail. The head and
  tail partitions hold uncompressed nodes, and the middle partition holds
  compressed nodes. Therefore,the time complexity of maintaining compress depth
  after adding or deleting a node will drop to O(1), moving at most one node
  from one partition to another.
- Removed annoying members recompress, attempted_compress and dont_compress from
  quicklist node structure
- Merge structure quicklistIter and quicklistEntry
- The historical parameter packed_threshold has been removed
  This is mentioned by @sundb and @oranagra in pull request redis#12568.
- Merge strategy is added
  That is that any adjacent node in quicklist can not be merged.

Why:
I tried to solve the issue I found earlier, but found myself stuck in a quagmire
because the issues kept coming up while I fix the old one, so I finally decided
to rewrite it.

Issues with the old one:
- A node which should be compressed stays raw
  This is due to by poor design of quicklist->recompress, the design forgot the
  situation that a node could stay uncompressed if it can not compress small
  enough. And if we changed the node, wo should perform compress on it again.
  See issue redis#12563.
- Iterator don't behave like iterator
  Iterator will be reset and not avaliable for further use after replace or
  insert, see marcro resetIterator(). The only operation that athe iterator does
  not get reset is quicklistDelEntry(), and it has a commment about it, but the
  comment is wrong, the iterator may not behave like the comment says.
  See issue redis#12614.
- Packed node violate size limit
  Certen call to function quicklistReplaceEntry(), quicklistInsertBefore() and
  quicklistInsertAfter() will cause a packed node violate size limit.
  See issue redis#12548.
- Merge operation only performed in insert
  There is no merging in delete nor replace, which can make the quicklist
  contain adjacent small nodes.
  See issue redis#12856.
- Algorithms that maintain compress depth are not efficient
  the algorithm to maintain compress depth after add or delete is to check nodes
  on both sides of the list, time complexity is O(n), where n is the uncompressed
  depth on both sides of the list.

All the changes:
- Partition the node
  Divide the node into three partitions: head, middle and tail. The head and
  tail partitions hold uncompressed nodes, and the middle partition holds
  compressed nodes. Therefore,the time complexity of maintaining compress depth
  after adding or deleting a node will drop to O(1), moving at most one node
  from one partition to another.
- Removed annoying members recompress, attempted_compress and dont_compress from
  quicklist node structure
- Merge structure quicklistIter and quicklistEntry
- The historical parameter packed_threshold has been removed
  This is mentioned by @sundb and @oranagra in pull request redis#12568.
- Merge strategy is added
  That is that any adjacent node in quicklist can not be merged.

Why:
I tried to solve the issue I found earlier, but found myself stuck in a quagmire
because the issues kept coming up while I fix the old one, so I finally decided
to rewrite it.

Issues with the old one:
- A node which should be compressed stays raw
  This is due to by poor design of quicklist->recompress, the design forgot the
  situation that a node could stay uncompressed if it can not compress small
  enough. And if we changed the node, wo should perform compress on it again.
  See issue redis#12563.
- Iterator don't behave like iterator
  Iterator will be reset and not avaliable for further use after replace or
  insert, see marcro resetIterator(). The only operation that athe iterator does
  not get reset is quicklistDelEntry(), and it has a commment about it, but the
  comment is wrong, the iterator may not behave like the comment says.
  See issue redis#12614.
- Packed node violate size limit
  Certen call to function quicklistReplaceEntry(), quicklistInsertBefore() and
  quicklistInsertAfter() will cause a packed node violate size limit.
  See issue redis#12548.
- Merge operation only performed in insert
  There is no merging in delete nor replace, which can make the quicklist
  contain adjacent small nodes.
  See issue redis#12856.
- Algorithms that maintain compress depth are not efficient
  the algorithm to maintain compress depth after add or delete is to check nodes
  on both sides of the list, time complexity is O(n), where n is the uncompressed
  depth on both sides of the list.

All the changes:
- Partition the node
  Divide the node into three partitions: head, middle and tail. The head and
  tail partitions hold uncompressed nodes, and the middle partition holds
  compressed nodes. Therefore,the time complexity of maintaining compress depth
  after adding or deleting a node will drop to O(1), moving at most one node
  from one partition to another.
- Removed annoying members recompress, attempted_compress and dont_compress from
  quicklist node structure
- Merge structure quicklistIter and quicklistEntry
- The historical parameter packed_threshold has been removed
  This is mentioned by @sundb and @oranagra in pull request redis#12568.
- Merge strategy is added
  That is that any adjacent node in quicklist can not be merged.

Following #12568

In issue #9357, when inserting an element larger than 1GB, we currently
store it in a plain node instead of a listpack.
Presently, when we insert an element that exceeds the maximum size of a
packed node, it cannot be accommodated in any other nodes, thus ending
up isolated like a large element.
I.e. it's a node with only one element, but it's listpack encoded rather
than a plain buffer.

This PR lowers the threshold for considering an element as 'large' from
1GB to the maximum size of a node.
While this change doesn't completely resolve the bug mentioned in the
previous PR, it does mitigate its potential impact.

As a result of this change, we can now only use LSET to replace an
element with another element that falls below the maximum size
threshold.
In the worst-case scenario, with a fill of -5, the largest packed node
we can create is 2GB (32k * 64k):
* 32k: The smallest element in a listpack is 2 bytes, which allows us to
store up to 32k elements.
* 64k: This is the maximum size for a single quicklist node.

## Others
To fully fix #9357, we need more work, as discussed in #12568, when we
insert an element into a quicklistNode, it may be created in a new node,
put into another node, or merged, and we can't correctly delete the node
that was supposed to be deleted.
I'm not sure it's worth it, since it involves a lot of modifications.