Fix GH#96: remove undeclared Try::Tiny dep, add non-blocking blead CI

[oalders]

Closes #96

Problem

t/diag.t did use Try::Tiny qw( try ); but Try::Tiny was never declared as a test prerequisite (not in cpanfile, META.json, or Makefile.PL).

On a freshly built perl that does not already have Try::Tiny installed — e.g. blead 5.45.1, as reported via IRC by @Tux — the CPAN toolchain does not pull it in, so t/diag.t dies at compile time:

Can't locate Try/Tiny.pm in @INC
BEGIN failed--compilation aborted at t/diag.t line 13.

make test then fails, so the distribution appears not to install. The stable CI matrix tops out at 5.42 and the test-job installs only the declared cpanfile deps, so nothing currently catches this on the upcoming Perl.

Changes

1. Remove the undeclared Try::Tiny dependency (t/diag.t)
The two try { ... } blocks only swallowed exceptions around diagnostic Net::SSLeay version calls — no catch. A plain eval { ...; 1 } or diag(...) is equivalent, so this drops the dependency entirely rather than adding it to the prereqs. Fewer test deps keeps the suite installable on minimal/blead perls, which is the whole point of the report. (Try::Tiny was the only undeclared test prereq — audited all of t/*.t.)

2. Add a non-blocking blead CI job (.github/workflows/dzil-build-and-test.yml)
A container job on perldocker/perl-tester:devel (tracks the latest Perl development release) that installs the declared deps and runs the suite. It has no continue-on-error, so a break shows up as a visible red X — but it is meant to be kept out of the required status checks in branch protection, so blead breakage never blocks a merge. This is the early-warning signal the stable matrix couldn't give for #96.

Testing

• Reproduced the exact symptom with a red-green cycle by hiding Try::Tiny via an @INC hook:
  • RED (original t/diag.t): exit 255, BEGIN failed--compilation aborted.
  • GREEN (this change): exit 0, t/diag.t passes; the eval guard still catches the LIBRESSL_VERSION_NUMBER die and continues.
• t/diag.t passes with Try::Tiny both present and absent.
• perltidy reports no changes; perl -c OK.
• t/https_proxy.t / t/example.t unchanged (need local sockets / internet unavailable in the dev sandbox; unaffected by this change).
• Workflow YAML validated (parses; blead job wired to needs: build-job, devel image, no continue-on-error). The blead job itself will run for real on this PR.

Notes

• The project perl-review STANDARDS prefer Try::Tiny over eval; that preference is intentionally overridden here since the dependency itself is the cause of the install failure. Confirmed with the maintainer.
• Caveat on the blead job: perl-tester:devel is a "fat" image with many modules preinstalled, so it reliably catches genuine blead code/test breakage but may not catch a future undeclared-prereq regression the way a truly minimal perl would. It's the reliable signal available given this repo's container-based CI; a strict minimal-prereq blead check would need a from-scratch perl build.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.33%. Comparing base (83516ee) to head (4d52ee4).

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #98   +/-   ##
=======================================
  Coverage   58.33%   58.33%           
=======================================
  Files           1        1           
  Lines          48       48           
  Branches       14       14           
=======================================
  Hits           28       28           
  Misses         11       11           
  Partials        9        9           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Leont]

A plain eval { ...; 1 } or diag(...) is equivalent

I don't think it is. Previously it failed silently? Especially in the second case, for the vast majority of users on on OpenSSL the absence of a LibreSSL version number is entirely expected. Presenting a diag about that doesn't seem helpful.

[Leont]

But I'm also wondering why it's using eval/try in the first place. Wouldn't it be easier to write something like:

diag(sprintf 'OpenSSL version number 0x%08x', Net::SSLeay::OPENSSL_VERSION_NUMBER())
    if Net::SSLeay->can('OPENSSL_VERSION_NUMBER');