Fix dmu_tx_dirty_throttle after initial arc_c reduction.

[amotin]

After initial arc_c was reduced to arc_c_min it became possible that on datasets with primarycache=metadata or none dirty data make up most of ARC capacity and easily more than configured 50% of initial arc_c, that causes forced txg commits by arc_tempreserve_space() and periodic very long write delays.

This patch makes arc_tempreserve_space() to use arc_c only after ARC warmed up once and arc_c really means something, but use arc_c_max before that.

How Has This Been Tested?

On freshly booted FreeBSD head created dataset with primarycache=metadata and started writing it sequentially while pressing Ctrl+T to see its call stack and measuring the write call latency. With the patch I see proper write throttling and pretty stable latency about 1ms instead of regular delay jumps up to 5-6 seconds otherwise, waiting for TXG commits.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[ghost]

I wonder where else this logic might be applicable.
l2arc_hdr_limit_reached has arc_warm ? arc_c : arc_c_max as well.

static boolean_t
l2arc_hdr_limit_reached(void)
{
        int64_t s = aggsum_upper_bound(&astat_l2_hdr_size);

        return (arc_reclaim_needed() || (s > arc_meta_limit * 3 / 4) ||
            (s > (arc_warm ? arc_c : arc_c_max) * l2arc_meta_percent / 100));
}

[amotin]

@freqlabs I've looked through all other arc_c use cases and found no candidates other than those two.