Local deploy versioning

[marcelldls]

For facilities that adopt a CalVer scheme of YYYY.MM.MINOR as suggested in the documentation - the automatically generated local-deploy versioning can be misleading. For example:

            name ready restarts              started  namespace      app_version
bl01c-di-dcam-01  true        2 2024-02-20T12:57:59Z b01-1-iocs         2024.2.4
bl01c-di-dcam-02  true        0 2024-02-20T10:54:02Z b01-1-iocs         2024.2.5
bl01c-ea-test-01  true        0 2024-02-20T13:16:27Z b01-1-iocs         2024.2.6
 bl01c-mo-ioc-01  true        0 2024-02-22T16:53:24Z b01-1-iocs 2024.2.5-b16.52
      epics-opis  true        0 2024-02-19T14:30:17Z b01-1-iocs         2024.2.4

One might confuse that the 2024.2.5-b16.52 tag is a local edit of the repository at2024.2.5 however it follows a YYYY.MM.DD convention which could be said to be inconsistent with the suggested versioning.

This PR introduces the following for ec deploy_local

• A YYYY.MM.MINOR-b scheme where MINOR is derived from the base 32 representation of the Day.hour.minute.seconds
• This also addresses the current clash of version name for deploying multiple times within one minute (by including seconds) but still reduces the length of the version

An example of the new output is

            name ready restarts              started  namespace   app_version
bl01c-di-dcam-01  true        2 2024-02-20T12:57:59Z b01-1-iocs      2024.2.4
bl01c-di-dcam-02  true        0 2024-02-20T10:54:02Z b01-1-iocs      2024.2.5
bl01c-ea-test-01  true        0 2024-02-20T13:16:27Z b01-1-iocs      2024.2.6
 bl01c-mo-ioc-01  true        0 2024-02-27T16:28:43Z b01-1-iocs 2024.2.1PSC-b
      epics-opis  true        0 2024-02-19T14:30:17Z b01-1-iocs      2024.2.4

[marcelldls]

I'm pretty happy with this.

Is numpy a rather big for such a small feature?

I mean I can hardly complain with my pandas inclusion for table formatting ...

You are right, but because numpy is already part of pandas I thought I would just leave this in for convenience as a proof of concept. Now that we got rid of pandas, I could include our own implementation but perhaps the best is actually just to use the built in decimal to hex base convert rather than the base 32 I used. The cost is instead of the longest version being XXXX.XX.2HNK0-b it would be XXXX.XX.28DE80-b

[gilesknap]

OK well I'm pretty happy either way on that one.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 79.28%. Comparing base (6f7c3a6) to head (1e7bfc9).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #105 +/- ## ========================================== + Coverage 79.14% 79.28% +0.13% ========================================== Files 14 14 Lines 892 898 +6 ========================================== + Hits 706 712 +6 Misses 186 186 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.