Analyze Gitlab::Metrics.counter invocation performance

The following discussion from !17068 (merged) should be addressed:

• Analyze trade-off of memoizing the counter vs dynamic invocation
• Document a best practice
• Review other places where we already use a counter

• @ayufan started a discussion: (+2 comments)

  I wonder. How expensive is to use Gitlab::Metrics.counter dynamically?

  I know that we use that approach in different places, but maybe it would be better to have:

  def self.internal_id_for_update_lock_counter
    strong_memoize(:internal_id_for_update_lock_counter) do 
   
   Gitlab::Metrics.counter(:gitlab_internal_id_for_update_lock, 'Number of ROW SHARE (FOR UPDATE) locks on individual records from internal_ids')
    end
  end
  
  def update_and_save(&block)
   
   self.class.internal_id_for_update_lock_counter.increment
  
    ...
  end

  I'm fine with keeping it as-is, but I wonder if this approach would simply not be better.