feat: Limit for blocking ingestion until configured date

[salvacorts]

What this PR does / why we need it:
This PR introduces two new limits to block ingestion until a configurable date.

• block_ingestion_until: Configures the date till when Loki will block ingestion
• block_ingestion_status_code: Configures the status code to return when ingestion is blocked.
  • By default we return a custom status code (260). If it's configured to 200, we block, log the error in Loki, but return a success response to the client.
  • This limit gives us flexibility to customise the status code per client.

When ingestion is blocked, the discarded bytes and lines metric are updated with a new reason: blocked_ingestion.

Special notes for your reviewer:

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[vlad-diachenko]

looks ideal ... let's just change the default status code

[vlad-diachenko]

according to discussions in the design doc, it looks like we need to return successful status code by default, some 2xx ...
it will guarantee us that regardless of the client type, the clients won't re-send us the data

[salvacorts]

Done